Loadcat ile Basitleştirilmiş NGINX Yük Dengeleme

Yatay olarak ölçeklenebilir olacak şekilde tasarlanan web uygulamaları genellikle bir veya daha fazla yük dengeleme düğümü gerektirir. Birincil amaçları, gelen trafiği mevcut web sunucuları arasında adil bir şekilde dağıtmaktır. Yalnızca düğüm sayısını artırarak ve yük dengeleyicilerin bu değişikliğe uyum sağlamasını sağlayarak bir web uygulamasının genel kapasitesini artırma yeteneği, üretimde son derece yararlı olduğunu kanıtlayabilir.

NGINX, diğer özelliklerinin yanı sıra yüksek performanslı yük dengeleme özellikleri sunan bir web sunucusudur. Bu özelliklerden bazıları yalnızca abonelik modellerinin bir parçası olarak mevcuttur, ancak ücretsiz ve açık kaynak sürümü hala çok zengin özelliklere sahiptir ve kutudan çıktığı gibi en temel yük dengeleme özellikleriyle birlikte gelir.

Bu öğreticide, düzgün bir web sağlayarak NGINX yapılandırma dosyalarının tüm önemli ayrıntılarını soyutlayarak, NGINX örneğinizi anında bir yük dengeleyici görevi görecek şekilde yapılandırmanıza olanak tanıyan deneysel bir aracın iç mekaniğini keşfedeceğiz. tabanlı kullanıcı arayüzü. Bu makalenin amacı, böyle bir araç oluşturmaya başlamanın ne kadar kolay olduğunu göstermektir. Loadcat projesinin büyük ölçüde Linode'un NodeBalancers'ından ilham aldığını belirtmekte fayda var.

NGINX, Sunucular ve Yukarı Akışlar

NGINX'in en popüler kullanımlarından biri, istemcilerden web sunucusu uygulamalarına yapılan istekleri ters proxy yapmaktır. Node.js ve Go gibi programlama dillerinde geliştirilen web uygulamaları kendi kendine yeterli web sunucuları olabilse de, gerçek sunucu uygulamasının önünde bir ters proxy bulunması sayısız fayda sağlar. Bir NGINX yapılandırma dosyasında bunun gibi basit bir kullanım durumu için bir "sunucu" bloğu şöyle görünebilir:

 server { listen 80; server_name example.com; location / { proxy_pass http://192.168.0.51:5000; } }

Bu, NGINX'in example.com'a yönlendirilen tüm istekleri 80 numaralı bağlantı noktasında dinlemesini ve her birini 192.168.0.51:5000'de çalışan bazı web sunucusu uygulamalarına geçirmesini sağlar. Web uygulama sunucusu yerel olarak çalışıyorsa, burada 127.0.0.1 geri döngü IP adresini de kullanabiliriz. Lütfen yukarıdaki snippet'in, ters proxy yapılandırmasında sıklıkla kullanılan bazı bariz ince ayarlardan yoksun olduğunu, ancak kısa olması için bu şekilde tutulduğunu unutmayın.

Peki ya aynı web uygulama sunucusunun iki örneği arasında gelen tüm istekleri dengelemek istersek? Bu, "yukarı akış" yönergesinin yararlı olduğu yerdir. NGINX'te, "upstream" yönergesi ile, NGINX'in gelen tüm istekleri dengeleyeceği birden fazla arka uç düğümü tanımlamak mümkündür. Örneğin:

 upstream nodes { server 192.168.0.51:5000; server 192.168.0.52:5000; } server { listen 80; server_name example.com; location / { proxy_pass http://nodes; } }

İki sunucudan oluşan "nodes" adlı bir "upstream" bloğu nasıl tanımladığımıza dikkat edin. Her sunucu bir IP adresi ve dinledikleri port numarası ile tanımlanır. Bununla NGINX, en basit haliyle bir yük dengeleyici haline gelir. Varsayılan olarak, NGINX gelen istekleri, ilki birinci sunucuya, ikincisi ikinci sunucuya, üçüncüsü birinci sunucuya vb.

Bununla birlikte, yük dengeleme söz konusu olduğunda NGINX'in sunabileceği çok şey vardır. Her sunucu için ağırlıklar tanımlamanıza, onları geçici olarak kullanılamıyor olarak işaretlemenize, farklı bir dengeleme algoritması seçmenize (örneğin, müşterinin IP karmasına dayalı olarak çalışan bir algoritma var) vb. olanak tanır. Bu özellikler ve yapılandırma yönergelerinin tümü nginx.org'da güzel bir şekilde belgelenmiştir. . Ayrıca NGINX, konfigürasyon dosyalarının neredeyse hiç kesinti olmadan anında değiştirilmesine ve yeniden yüklenmesine izin verir.

NGINX'in yapılandırılabilirliği ve basit yapılandırma dosyaları, onu birçok ihtiyaca uyarlamayı gerçekten kolaylaştırır. Ve internette NGINX'i bir yük dengeleyici olarak tam olarak nasıl yapılandıracağınızı öğreten çok sayıda öğretici zaten var.

Loadcat: NGINX Yapılandırma Aracı

Programların kendi başlarına bir şey yapmak yerine, bunu onlar için yapacak diğer araçları yapılandıran büyüleyici bir yanı vardır. Kullanıcı girdilerini alıp birkaç dosya oluşturmaktan başka pek bir şey yapmıyorlar. Bu araçlardan elde ettiğiniz faydaların çoğu aslında diğer araçların özellikleridir. Ancak, kesinlikle hayatı kolaylaştırıyorlar. Kendi projelerimden biri için bir yük dengeleyici kurmaya çalışırken merak ettim: neden NGINX ve yük dengeleme yetenekleri için benzer bir şey yapmıyorsunuz?

Yük kedisi doğdu!

Go ile inşa edilen Loadcat, henüz emekleme aşamasındadır. Şu anda araç, NGINX'i yalnızca yük dengeleme ve SSL sonlandırması için yapılandırmanıza izin verir. Kullanıcı için basit bir web tabanlı GUI sağlar. Aracın özelliklerini tek tek incelemek yerine, altında ne olduğuna bir göz atalım. Yine de, birisi NGINX yapılandırma dosyalarıyla elle çalışmaktan hoşlanıyorsa, böyle bir araçta çok az değer bulabileceklerini unutmayın.

Bunun için programlama dili olarak Go'yu seçmenin birkaç nedeni var. Bunlardan biri Go'nun derlenmiş ikili dosyalar üretmesidir. Bu, bağımlılıkları çözme endişesi olmadan Loadcat'i derlenmiş bir ikili dosya olarak uzak sunuculara oluşturup dağıtmamıza veya dağıtmamıza olanak tanır. Kurulum sürecini büyük ölçüde basitleştiren bir şey. Elbette ikili dosya, NGINX'in zaten kurulu olduğunu ve bunun için bir systemd birim dosyasının bulunduğunu varsayar.

Go mühendisi değilseniz endişelenmeyin. Go ile başlamak oldukça kolay ve eğlencelidir. Ayrıca, uygulamanın kendisi çok basittir ve kolayca takip edebilmelisiniz.

Yapı

Git derleme araçları, uygulamanızı nasıl yapılandırabileceğiniz konusunda birkaç kısıtlama getirin ve gerisini geliştiriciye bırakın. Bizim durumumuzda, amaçlarına göre işleri birkaç Go paketine ayırdık:

• cfg: yapılandırma değerlerini yükler, ayrıştırır ve sağlar
• cmd/loadcat: ana paket, giriş noktasını içerir, ikili dosyada derlenir
• veri: "modeller" içerir, kalıcılık için gömülü bir anahtar/değer deposu kullanır
• kedi: temel işlevleri içerir, örneğin yapılandırma dosyalarının oluşturulması, yeniden yükleme mekanizması, vb.
• ui: şablonları, URL işleyicilerini vb. içerir.

Paket yapısına, özellikle kedi paketine daha yakından bakarsak, NGINX'e özgü tüm kodların bir feline/nginx alt paketinde tutulduğunu fark edeceğiz. Bu, uygulama mantığının geri kalanını genel tutabilmemiz ve gelecekte diğer yük dengeleyiciler (örn. HAProxy) için desteği genişletebilmemiz için yapılır.

Giriş noktası

“cmd/loadcatd” içinde bulunan Loadcat için ana paketten başlayalım. Ana işlev, uygulamanın giriş noktası, üç şey yapar.

 func main() { fconfig := flag.String("config", "loadcat.conf", "") flag.Parse() cfg.LoadFile(*fconfig) feline.SetBase(filepath.Join(cfg.Current.Core.Dir, "out")) data.OpenDB(filepath.Join(cfg.Current.Core.Dir, "loadcat.db")) defer data.DB.Close() data.InitDB() http.Handle("/api", api.Router) http.Handle("/", ui.Router) go http.ListenAndServe(cfg.Current.Core.Address, nil) // Wait for an “interrupt“ signal (Ctrl+C in most terminals) }

İşleri basit tutmak ve kodun daha kolay okunmasını sağlamak için, tüm hata işleme kodları yukarıdaki parçadan (ve ayrıca bu makalenin ilerleyen bölümlerindeki parçacıklardan) kaldırılmıştır.

Koddan da anlaşılacağı gibi, yapılandırma dosyasını “-config” komut satırı bayrağına (geçerli dizinde varsayılan olarak “loadcat.conf” olarak) dayalı olarak yüklüyoruz. Ardından, çekirdek kedi paketi ve veritabanı olmak üzere birkaç bileşeni başlatıyoruz. Son olarak, web tabanlı GUI için bir web sunucusu başlatıyoruz.

Yapılandırma

Yapılandırma dosyasını yüklemek ve ayrıştırmak muhtemelen buradaki en kolay kısımdır. Yapılandırma bilgilerini kodlamak için TOML kullanıyoruz. Go için temiz bir TOML ayrıştırma paketi mevcuttur. Kullanıcıdan çok az yapılandırma bilgisine ihtiyacımız var ve çoğu durumda bu değerler için aklı başında varsayılanları belirleyebiliriz. Aşağıdaki yapı , yapılandırma dosyasının yapısını temsil eder:

 struct { Core struct { Address string Dir string Driver string } Nginx struct { Mode string Systemd struct { Service string } } }

Ve tipik bir "loadcat.conf" dosyası şöyle görünebilir:

 [core] address=":26590" dir="/var/lib/loadcat" driver="nginx" [nginx] mode="systemd" [nginx.systemd] service="nginx.service"

Gördüğümüz gibi, TOML kodlu yapılandırma dosyasının yapısı ile üzerinde gösterilen yapı arasında bir benzerlik vardır. Yapılandırma paketi, yapının belirli alanları için bazı makul varsayılanları ayarlayarak başlar ve ardından yapılandırma dosyasını bunun üzerinde ayrıştırır. Belirtilen yolda bir yapılandırma dosyası bulamazsa, bir tane oluşturur ve ilk olarak varsayılan değerleri bu dosyaya atar.

 func LoadFile(name string) error { f, _ := os.Open(name) if os.IsNotExist(err) { f, _ = os.Create(name) toml.NewEncoder(f).Encode(Current) f.Close() return nil } toml.NewDecoder(f).Decode(&Current) return nil }

Veri ve Kalıcılık

Bolt'la tanışın. Saf Go ile yazılmış gömülü bir anahtar/değer deposu. Çok basit bir API'ye sahip bir paket olarak gelir, kutudan çıktığı gibi işlemleri destekler ve rahatsız edici derecede hızlıdır.

Paket verileri içinde, her bir varlık türünü temsil eden yapılara sahibiz. Örneğin, elimizde:

 type Balancer struct { Id bson.ObjectId Label string Settings BalancerSettings } type Server struct { Id bson.ObjectId BalancerId bson.ObjectId Label string Settings ServerSettings }

… burada bir Dengeleyici örneği, tek bir yük dengeleyiciyi temsil eder. Loadcat, tek bir NGINX örneği aracılığıyla birden çok web uygulamasına yönelik istekleri etkili bir şekilde dengelemenize olanak tanır. Her dengeleyicinin arkasında, her sunucunun ayrı bir arka uç düğüm olabileceği bir veya daha fazla sunucu olabilir.

Bolt bir anahtar/değer deposu olduğundan ve gelişmiş veritabanı sorgularını desteklemediğinden, bunu bizim için yapan uygulama tarafı mantığına sahibiz. Loadcat, her birinde binlerce sunucu bulunan binlerce dengeleyiciyi yapılandırmak için tasarlanmamıştır, bu nedenle doğal olarak bu saf yaklaşım gayet iyi çalışır. Ayrıca Bolt, bayt dilimleri olan anahtarlar ve değerlerle çalışır ve bu nedenle yapıları Bolt'ta saklamadan önce BSON kodlaması yaparız. Veritabanından Balancer yapılarının bir listesini alan bir fonksiyonun uygulaması aşağıda gösterilmiştir:

 func ListBalancers() ([]Balancer, error) { bals := []Balancer{} DB.View(func(tx *bolt.Tx) error { b := tx.Bucket([]byte("balancers")) c := b.Cursor() for k, v := c.First(); k != nil; k, v = c.Next() { bal := Balancer{} bson.Unmarshal(v, &bal) bals = append(bals, bal) } return nil }) return bals, nil }

ListBalancers işlevi salt okunur bir işlem başlatır, "dengeleyiciler" paketindeki tüm anahtarlar ve değerler üzerinde yinelenir, her bir değerin kodunu bir Balancer yapısı örneğine çözer ve bunları bir dizide döndürür.

Kovada bir dengeleyici saklamak neredeyse aynı derecede basittir:

 func (l *Balancer) Put() error { if !l.Id.Valid() { l.Id = bson.NewObjectId() } if l.Label == "" { l.Label = "Unlabelled" } if l.Settings.Protocol == "https" { // Parse certificate details } else { // Clear fields relevant to HTTPS only, such as SSL options and certificate details } return DB.Update(func(tx *bolt.Tx) error { b := tx.Bucket([]byte("balancers")) p, err := bson.Marshal(l) if err != nil { return err } return b.Put([]byte(l.Id.Hex()), p) }) }

Put işlevi belirli alanlara bazı varsayılan değerler atar, HTTPS kurulumunda ekli SSL sertifikasını ayrıştırır, bir işlem başlatır, yapı örneğini kodlar ve onu dengeleyicinin kimliğine göre kovada saklar.

SSL sertifikası ayrıştırılırken, standart paket kodlama/pem kullanılarak iki parça bilgi çıkarılır ve Ayarlar alanı altındaki SSLOptions'da saklanır: DNS adları ve parmak izi.

Ayrıca sunucuları dengeleyiciye göre arayan bir fonksiyonumuz var:

 func ListServersByBalancer(bal *Balancer) ([]Server, error) { srvs := []Server{} DB.View(func(tx *bolt.Tx) error { b := tx.Bucket([]byte("servers")) c := b.Cursor() for k, v := c.First(); k != nil; k, v = c.Next() { srv := Server{} bson.Unmarshal(v, &srv) if srv.BalancerId.Hex() != bal.Id.Hex() { continue } srvs = append(srvs, srv) } return nil }) return srvs, nil }

Bu işlev, yaklaşımımızın gerçekte ne kadar saf olduğunu gösterir. Burada, diziyi döndürmeden önce tüm "sunucular" paketini etkili bir şekilde okuyor ve alakasız varlıkları filtreliyoruz. Ama sonra tekrar, bu gayet iyi çalışıyor ve onu değiştirmek için gerçek bir sebep yok.

Sunucular için Put işlevi, çok sayıda kod satırı ayarı varsayılanı ve hesaplanmış alan gerektirmediğinden Balancer struct işlevinden çok daha basittir.

NGINX'i kontrol etme

Loadcat'i kullanmadan önce, oluşturulan yapılandırma dosyalarını yüklemek için NGINX'i yapılandırmamız gerekir. Loadcat, dengeleyici kimliğine göre (kısa bir hex dizesi) bir dizin altındaki her dengeleyici için “nginx.conf” dosyası oluşturur. Bu dizinler cwd bir "out" dizini altında oluşturulur. Bu nedenle, oluşturulan bu yapılandırma dosyalarını yüklemek için NGINX'i yapılandırmanız önemlidir. Bu, "http" bloğu içindeki bir "include" yönergesi kullanılarak yapılabilir:

/etc/nginx/nginx.conf dosyasını düzenleyin ve “http” bloğunun sonuna aşağıdaki satırı ekleyin:

 http { include /path/to/out/*/nginx.conf; }

Bu, NGINX'in “/path/to/out/” altında bulunan tüm dizinleri taramasına, her dizinde “nginx.conf” adlı dosyaları aramasına ve bulduğu her birini yüklemesine neden olacaktır.

Çekirdek paketimizde kedi, bir arayüz Sürücüsü tanımlıyoruz. Doğru imzayla Generate ve Reload olmak üzere iki işlev sağlayan herhangi bir yapı , bir sürücü olarak nitelendirilir.

 type Driver interface { Generate(string, *data.Balancer) error Reload() error }

Örneğin, feline/nginx paketlerinin altındaki Nginx yapısı:

 type Nginx struct { sync.Mutex Systemd *dbus.Conn } func (n Nginx) Generate(dir string, bal *data.Balancer) error { // Acquire a lock on n.Mutex, and release before return f, _ := os.Create(filepath.Join(dir, "nginx.conf")) TplNginxConf.Execute(f, /* template parameters */) f.Close() if bal.Settings.Protocol == "https" { // Dump private key and certificate to the output directory (so that Nginx can find them) } return nil } func (n Nginx) Reload() error { // Acquire a lock on n.Mutex, and release before return switch cfg.Current.Nginx.Mode { case "systemd": if n.Systemd == nil { c, err := dbus.NewSystemdConnection() n.Systemd = c } ch := make(chan string) n.Systemd.ReloadUnit(cfg.Current.Nginx.Systemd.Service, "replace", ch) <-ch return nil default: return errors.New("unknown Nginx mode") } }

Generate , çıktı dizininin yolunu içeren bir dize ve bir Balancer yapı örneğine bir işaretçi ile çağrılabilir. Go, NGINX sürücüsünün son NGINX yapılandırma dosyasını oluşturmak için kullandığı metin şablonlama için standart bir paket sağlar. Şablon, dengeleyicinin nasıl yapılandırıldığına bağlı olarak oluşturulan bir "sunucu" bloğunun izlediği bir "yukarı akış" bloğundan oluşur:

 var TplNginxConf = template.Must(template.New("").Parse(` upstream {{.Balancer.Id.Hex}} { {{if eq .Balancer.Settings.Algorithm "least-connections"}} least_conn; {{else if eq .Balancer.Settings.Algorithm "source-ip"}} ip_hash; {{end}} {{range $srv := .Balancer.Servers}} server {{$srv.Settings.Address}} weight={{$srv.Settings.Weight}} {{if eq $srv.Settings.Availability "available"}}{{else if eq $srv.Settings.Availability "backup"}}backup{{else if eq $srv.Settings.Availability "unavailable"}}down{{end}}; {{end}} } server { {{if eq .Balancer.Settings.Protocol "http"}} listen {{.Balancer.Settings.Port}}; {{else if eq .Balancer.Settings.Protocol "https"}} listen {{.Balancer.Settings.Port}} ssl; {{end}} server_name {{.Balancer.Settings.Hostname}}; {{if eq .Balancer.Settings.Protocol "https"}} ssl on; ssl_certificate {{.Dir}}/server.crt; ssl_certificate_key {{.Dir}}/server.key; {{end}} location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://{{.Balancer.Id.Hex}}; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; } } `))

Yeniden yükle , NGINX'in yapılandırma dosyalarını yeniden yüklemesini sağlayan Nginx yapısındaki diğer işlevdir. Kullanılan mekanizma, Loadcat'in nasıl yapılandırıldığına bağlıdır. Varsayılan olarak, NGINX'in nginx.service olarak çalışan bir systemd hizmeti olduğunu varsayar, öyle ki [sudo] systemd reload nginx.service çalışır. Ancak bir kabuk komutu yürütmek yerine, github.com/coreos/go-systemd/dbus paketini kullanarak D-Bus aracılığıyla systemd ile bağlantı kurar.

Web tabanlı GUI

Tüm bu bileşenler yerinde olduğunda, hepsini sade bir Bootstrap kullanıcı arayüzü ile tamamlayacağız.

Bu temel işlevler için birkaç basit GET ve POST yol işleyicisi yeterlidir:

 GET /balancers GET /balancers/new POST /balancers/new GET /balancers/{id} GET /balancers/{id}/edit POST /balancers/{id}/edit GET /balancers/{id}/servers/new POST /balancers/{id}/servers/new GET /servers/{id} GET /servers/{id}/edit POST /servers/{id}/edit

Her bir rotanın üzerinden geçmek burada yapılacak en ilginç şey olmayabilir, çünkü bunlar hemen hemen CRUD sayfalarıdır. Bu yolların her biri için işleyicilerin nasıl uygulandığını görmek için paket kullanıcı arabirimi koduna bir göz atmaktan çekinmeyin.

Her işleyici işlevi, aşağıdakilerden birini gerçekleştiren bir rutindir:

• Veri deposundan veri alır ve işlenmiş şablonlarla yanıt verir (getirilen verileri kullanarak)
• Gelen form verilerini ayrıştırır, veri deposunda gerekli değişiklikleri yapar ve NGINX yapılandırma dosyalarını yeniden oluşturmak için paket kediyi kullanır

Örneğin:

 func ServeServerNewForm(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) bal, _ := data.GetBalancer(bson.ObjectIdHex(vars["id"])) TplServerNewForm.Execute(w, struct { Balancer *data.Balancer }{ Balancer: bal, }) } func HandleServerCreate(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) bal, _ := data.GetBalancer(bson.ObjectIdHex(vars["id"])) r.ParseForm() body := struct { Label string `schema:"label"` Settings struct { Address string `schema:"address"` } `schema:"settings"` }{} schema.NewDecoder().Decode(&body, r.PostForm) srv := data.Server{} srv.BalancerId = bal.Id srv.Label = body.Label srv.Settings.Address = body.Settings.Address srv.Put() feline.Commit(bal) http.Redirect(w, r, "/servers/"+srv.Id.Hex()+"/edit", http.StatusSeeOther) }

ServeServerNewForm işlevinin tüm yaptığı, veri deposundan bir dengeleyici getirmesi ve bu durumda dengeleyicideki Sunucular işlevini kullanarak ilgili sunucuların listesini alan TplServerList adlı bir şablon oluşturmasıdır.

Bunun dışında HandleServerCreate işlevi, gövdeden gelen POST yükünü bir yapıya ayrıştırır ve bu verileri, dengeleyici için NGINX yapılandırma dosyasını yeniden oluşturmak üzere paket kediyi kullanmadan önce veri deposunda yeni bir Sunucu yapısını başlatmak ve sürdürmek için kullanır.

Tüm sayfa şablonları “ui/templates.go” dosyasında saklanır ve ilgili şablon HTML dosyaları “ui/templates” dizini altında bulunabilir.

Denemek

Loadcat'i uzak bir sunucuya veya hatta yerel ortamınıza dağıtmak çok kolaydır. Linux (64bit) kullanıyorsanız, havuzun Yayınlar bölümünden önceden oluşturulmuş bir Loadcat ikili dosyasına sahip bir arşiv alabilirsiniz. Biraz maceracı hissediyorsanız, depoyu klonlayabilir ve kodu kendiniz derleyebilirsiniz. Bununla birlikte, Go programlarını derlemek gerçekten zor olmadığı için bu durumdaki deneyim biraz hayal kırıklığı yaratabilir. Ve Arch Linux kullanıyorsanız, o zaman şanslısınız! Kolaylık sağlamak için dağıtım için bir paket oluşturulmuştur. Basitçe indirin ve paket yöneticinizi kullanarak kurun. İlgili adımlar, projenin README.md dosyasında daha ayrıntılı olarak özetlenmiştir.

Loadcat'i yapılandırıp çalıştırdıktan sonra, web tarayıcınızı “http://localhost:26590”a yönlendirin (yerel olarak çalıştığını ve 26590 numaralı bağlantı noktasını dinlediğini varsayarak). Ardından, bir dengeleyici oluşturun, birkaç sunucu oluşturun, bu tanımlanmış bağlantı noktalarında bir şeyin dinlediğinden emin olun ve işte, bu çalışan sunucular arasında gelen istekleri NGINX yük dengelemeniz gerekir.

Sıradaki ne?

Bu araç mükemmel olmaktan uzaktır ve aslında oldukça deneysel bir projedir. Araç, NGINX'in tüm temel işlevlerini bile kapsamıyor. Örneğin, NGINX katmanında arka uç düğümleri tarafından sunulan varlıkları önbelleğe almak istiyorsanız, yine de NGINX yapılandırma dosyalarını elle değiştirmeniz gerekecektir. Ve işleri heyecanlı kılan da bu. Burada yapılabilecek çok şey var ve sıradaki de tam olarak bu: NGINX'in yük dengeleme özelliklerinden daha fazlasını kapsamak - temel olanlar ve muhtemelen NGINX Plus'ın sunduğu özellikler.

Loadcat'i bir deneyin. Kodu kontrol et, çatalla, değiştir, onunla oyna. Ayrıca, başka bir yazılımı yapılandıran bir araç oluşturup oluşturmadığınızı veya aşağıdaki yorumlar bölümünde gerçekten beğendiğiniz bir aracı kullanıp kullanmadığınızı bize bildirin.