CasC'in F5 ile kullanılması, sürümden ve isteğe bağlı olarak dinamik ağ uç noktası yapılandırmasına izin vererek zaman tasarrufu sağlar ve riskleri azaltır.
Bu araç bunu destekliyor mu? Tek Konfigürasyon Dosyaları (SCF, F5 terimi) araç bunu yapıyor mu?
Yanıtlar:
Evet, F5'ler Kod Olarak Yapılandırmayı destekliyor. Tarihsel olarak F5, iControl XML API'sını kullanarak istemci uç noktası F5'leri (LTM'ler, vb.)
Oldukça hızlı bir şekilde bu yönetim cihazının korkunç olduğunu keşfettiler ve cihazları yönetmek için istemci cihazlarına (LTM'ler, vb. De iControl olarak da markalı) daha sağlam bir REST API eklediler, bu da kullanımı daha kolay ve daha esnek ve daha sonra Enterprise Manager, BIG-IQ markalı.
Mesele şu ki, bu REST arayüzünü kullanarak aynı API'yı yönetebilirsiniz. DevCentral ile ilgili eğiticilerine bakın . Genellikle, DevCentral sitesinde tam REST sözdizimini ve çağrılarını TMOS 12.1.0 için bu gibi sürüm başına temel olarak bulabilirsiniz .
Genel olarak konuşursak, birkaç nedenden dolayı hemen hemen bir SCF (Tek Yapılandırma Dosyası) kullanmanız önerilmez. Birincisi, SSL profilleriniz için sertifikalar ve anahtarlar veya komut dosyası ("harici" sağlık monitörleri) vb. Gibi destekleyici dosyalardan yoksundur. İkincisi, bölümler birkaç dosyaya yayıldığı için bölümleme kullanırsanız kötü oynatılır. katlanmış bir yapı. Bunlar bir SCF dosyasında iyi bir şekilde bir araya gelmez. Aslında TMOS komut dosyaları yazmak daha iyi olur. F5'in bigpipe komutundan TMOS kabuğuna geçmesinin nedenlerinden biri, bigpipe'ın kolayca komut dosyası yazılamadığı bir yerde yazılabilmesidir. Ancak yine REST API'sı tercih edilir. SCF'ler gerçekten TMOS 9 sürümünün bir mirasıdır ve 12 yaşında iyi yaşlanmadı ve kötü çalışıyor. Bunun önemli bir nedeni, kümelenmiş bir mimariye dönüştüklerinde HA'nın V10 ve V11 arasındaki bakışlarındaki değişikliklerden kaynaklanmaktadır. SCF'lerin kullanılabilirliğine gerçekten zarar verdi.
Kukla aslında bu yapılandırma yönetimi aracını kullanırsanız F5'leri yönetmek için bir modüle sahiptir ve tuzun bunun için bir koşucusu vardır - bu yapılandırma yönetim araçlarından birini kullanırsanız her ikisi de REST API'sini kullanır.
James, bu BIG-IQ'nun Enterprise Manager'ın yerini aldığı konusunda haklısın. Ancak Enterprise Manager gibi BIG-IQ da 'cihaz / özellik' yönetimi içindir. Doğrudan REST API'leriyle veya 3. taraf otomasyon araçlarına / araç zincirlerine entegre etmek için F5 iWorkflow'a (programlanabilir / genişletilebilir API ağ geçidi) bakmalısınız.
İWorkflow'un arkasındaki ekip 'servis şablonları' ve 'servis katalogları' üzerine odaklanmıştır. Bunlar, aynı görevi yerine getirmek için yüzlerce 'zorunlu arayüz' (bireysel REST uç noktaları) çağırmak yerine, tek REST çağrılarıyla vurabileceğiniz 'bildirici arayüzler' oluşturmak için harika yollar.
Deklaratif bir modele geçmek, sizi gelecekte ÇOK baş ağrılarından koruyacak ve otomasyonu ve CI / CD boru hatları ile entegrasyonu daha iyi destekleyecektir. İstediğiniz SON şey, altyapınızın tüm nüanslarını otomasyon boru hattının kendisine taşımaktır! Bildirici arayüz yoluyla soyutlama sizi bu çaresizlik çukurundan koruyacaktır.
REST + bildirici arabirimleri ile, kod modeli olarak çok daha basit bir Altyapıya sahip olursunuz, çünkü monolitik yapılandırma dosyaları için değil, yalnızca hizmet şablonları için JSON bloblarını korursunuz. Çift WIN!
REST API'sinden iApps (F5 hizmet şablonları) çağrısına bir göz atın. İşte ücretsiz çevrimiçi eğitim kursu:
http://f5-automation-labs.readthedocs.io/en/latest/
Chase = Doğru! Tüm yol boyunca REST!