Kubernetes'e dağıtımın ilk adımı uygulamanızı bir konteynere yerleştirmektir. Bu seride küçük, güvenli bir kapsayıcı görüntüsünü nasıl oluşturabileceğinize bakacağız.
Docker sayesinde konteyner görüntüleri oluşturmak hiç bu kadar kolay olmamıştı. Bir temel görüntü belirtin, değişikliklerinizi ekleyin ve bir kapsayıcı oluşturun.
Bu teknik başlangıç için harika olsa da, varsayılan temel görüntülerin kullanılması, güvenlik açıklarıyla dolu büyük görüntülerle güvenli olmayan çalışmalara yol açabilir.
Ek olarak, Docker'daki çoğu görüntü, temel görüntü için Debian veya Ubuntu'yu kullanır ve bu, mükemmel uyumluluk ve kolay özelleştirme sağlarken (Docker dosyası yalnızca iki satır kod alır), temel görüntüler, kapsayıcınıza yüzlerce megabayt ek yük ekleyebilir. Örneğin, bir Go "merhaba dünya" uygulaması için basit bir node.js dosyası yaklaşık 700 megabayt boyutundayken, gerçek uygulamanızın boyutu yalnızca birkaç megabayttır.
Dolayısıyla tüm bu ekstra iş yükü, dijital alan israfıdır ve güvenlik açıkları ve hatalar için harika bir saklanma alanıdır. Şimdi bir konteyner görüntüsünün boyutunu küçültmenin iki yoluna bakalım.
Birincisi küçük tabanlı görsellerin kullanılması, ikincisi ise Oluşturucu Deseninin kullanılmasıdır. Daha küçük temel görseller kullanmak muhtemelen konteynerinizin boyutunu azaltmanın en kolay yoludur. Büyük olasılıkla kullandığınız dil veya yığın, varsayılan görüntüden çok daha küçük bir orijinal uygulama görüntüsü sağlıyor. Node.js konteynerimize bir göz atalım.
Docker'da varsayılan olarak node:8 temel görüntü boyutu 670 MB'tır ve node: 8-alpine görüntü boyutu yalnızca 65 MB'dir, yani 10 kat daha küçüktür. Daha küçük Alp tabanı görüntüsünü kullanarak konteynerinizin boyutunu önemli ölçüde azaltacaksınız. Alpine, konteynerleri küçük tutarken birçok uygulamayla uyumlu olması nedeniyle Docker kullanıcıları arasında oldukça popüler olan küçük ve hafif bir Linux dağıtımıdır. Standart Docker "düğüm" görüntüsünün aksine, "node:alpine" birçok hizmet dosyasını ve programını kaldırır ve yalnızca uygulamanızı çalıştırmak için yeterli olanları bırakır.
Daha küçük bir temel görüntüye geçmek için yeni temel görüntüyle çalışmaya başlamak üzere Dockerfile'ı güncellemeniz yeterlidir:
Artık eski yerleşik görüntünün aksine, kodunuzu kapsayıcıya kopyalamanız ve tüm bağımlılıkları yüklemeniz gerekir. Yeni bir Docker dosyasında, kapsayıcı bir node:alpine görüntüsüyle başlar, ardından kod için bir dizin oluşturur, NPM paket yöneticisini kullanarak bağımlılıkları yükler ve son olarak server.js'yi çalıştırır.
Bu yükseltme, boyutun 10 kat daha küçük olduğu bir konteynerle sonuçlanır. Programlama diliniz veya yığınınız temel görüntü azaltma işlevine sahip değilse Alpine Linux kullanın. Ayrıca konteynerin içeriğini tam olarak yönetme olanağı da sağlayacaktır. Küçük temel görselleri kullanmak, hızlı bir şekilde küçük kaplar oluşturmanın harika bir yoludur. Ancak Oluşturucu Modeli kullanılarak daha da büyük bir azalma elde edilebilir.
Yorumlanan dillerde kaynak kodu önce yorumlayıcıya iletilir ve ardından doğrudan çalıştırılır. Derlenmiş dillerde kaynak kodu öncelikle derlenmiş koda dönüştürülür. Ancak derlemede genellikle kodu çalıştırmak için aslında gerekli olmayan araçlar kullanılır. Bu, bu aletleri son kaptan tamamen çıkarabileceğiniz anlamına gelir. Bunun için Builder Pattern'i kullanabilirsiniz.
Kod ilk kapta oluşturulur ve derlenir. Derlenen kod daha sonra, bu kodu derlemek için gereken derleyiciler ve araçlar olmadan son bir kaba paketlenir. Bu süreç üzerinden bir Go uygulaması çalıştıralım. İlk olarak yerleşik görüntüden Alpine Linux'a geçeceğiz.
Yeni Dockerfile'da kapsayıcı bir golang:alpine görüntüsüyle başlar. Daha sonra kod için bir dizin oluşturur, onu kaynak koduna kopyalar, kaynak kodunu oluşturur ve uygulamayı çalıştırır. Bu kapsayıcı, yerleşik kapsayıcıdan çok daha küçüktür, ancak yine de derleyiciyi ve aslında ihtiyacımız olmayan diğer Go araçlarını içerir. O halde derlenmiş programı çıkartıp kendi kabına koyalım.
Bu Docker dosyasında garip bir şey fark edebilirsiniz: iki FROM satırı içeriyor. İlk 4 satırlık bölüm, bu aşamayı adlandırmak için AS anahtar sözcüğünü kullanması dışında önceki Dockerfile ile tamamen aynı görünüyor. Sonraki bölümde yeni bir görüntü başlatmak için yeni bir FROM satırı var; burada golang:alpine görüntüsü yerine temel görüntü olarak Raw alpine'i kullanacağız.
Raw Alpine Linux'ta yüklü herhangi bir SSL sertifikası yok, bu da HTTPS üzerinden çoğu API çağrısının başarısız olmasına neden olacak, bu yüzden bazı kök CA sertifikalarını yükleyelim.
Şimdi işin eğlenceli kısmı geliyor: derlenmiş kodu birinci kaptan ikinciye kopyalamak için ikinci bölümün 5. satırında bulunan COPY komutunu kullanabilirsiniz. Yalnızca bir uygulama dosyasını kopyalar ve Go yardımcı program araçlarını etkilemez. Yeni çok aşamalı Docker dosyası, 12 megabayt olan orijinal konteyner görüntüsüne kıyasla yalnızca 700 megabayt boyutunda bir konteyner görüntüsü içerecektir, bu büyük bir farktır!
Bu nedenle, küçük temel görseller ve Oluşturucu Deseni kullanmak, çok fazla çalışma gerektirmeden çok daha küçük kaplar oluşturmanın harika yollarıdır.
Uygulama yığınına bağlı olarak görüntüyü ve kapsayıcı boyutunu küçültmenin ek yollarının olması mümkündür, ancak küçük kapsayıcıların gerçekten ölçülebilir bir faydası var mı? Küçük konteynerlerin son derece etkili olduğu iki alana bakalım: performans ve güvenlik.
Performans artışını değerlendirmek için kapsayıcı oluşturma, onu kayıt defterine ekleme (push) ve ardından oradan alma (çekme) sürecinin süresini göz önünde bulundurun. Daha küçük bir kabın daha büyük bir kaba göre belirgin bir avantajı olduğunu görebilirsiniz.
Docker katmanları önbelleğe alacağından sonraki derlemeler çok hızlı olacaktır. Ancak konteynerleri oluşturmak ve test etmek için kullanılan çoğu CI sistemi katmanları önbelleğe almaz, dolayısıyla önemli ölçüde zaman tasarrufu sağlanır. Gördüğünüz gibi, makinenizin gücüne bağlı olarak büyük bir konteyner inşa etme süresi 34 ila 54 saniye arasındadır ve Oluşturucu Deseni kullanılarak bir konteyner kullanıldığında 23'ten 28 saniyeye düşürülür. Bu tür operasyonlarda verimlilik artışı %40-50 olacaktır. Yani kodunuzu kaç kez oluşturup test ettiğinizi bir düşünün.
Kapsayıcı oluşturulduktan sonra, Kubernetes kümenizde kullanabilmeniz için görüntüsünü (kapsayıcı görüntüsünü aktar) kapsayıcı kayıt defterine göndermeniz gerekir. Google Container Registry'yi kullanmanızı öneririm.
Google Container Registry (GCR) ile yalnızca ham depolama ve ağ iletişimi için ödeme yaparsınız ve ek kapsayıcı yönetimi ücreti alınmaz. Özeldir, güvenlidir ve çok hızlıdır. GCR, çekme işlemini hızlandırmak için birçok numara kullanır. Gördüğünüz gibi go:onbuild kullanarak Docker Container Image konteynerini eklemek bilgisayar performansına bağlı olarak 15 ila 48 saniye sürecektir ve daha küçük bir konteynerle aynı işlem 14 ila 16 saniye sürecektir ve daha az verimli makineler için çalışma hızı avantajı 3 kat artar. Daha büyük makineler için süre hemen hemen aynıdır, çünkü GCR, paylaşılan bir görüntü veritabanı için genel bir önbellek kullanır; bu, onları hiçbir şekilde yüklemenize gerek olmadığı anlamına gelir. Düşük güçlü bir bilgisayarda CPU darboğazdır, dolayısıyla küçük kaplar kullanmanın avantajı burada çok daha fazladır.
GCR kullanıyorsanız derleme sisteminizin bir parçası olarak Google Container Builder'ı (GCB) kullanmanızı şiddetle tavsiye ederim.
Gördüğünüz gibi kullanımı, Build+Push işleminin süresini üretken bir makineden bile azaltmada çok daha iyi sonuçlar elde etmenize olanak tanır - bu durumda, konteyner oluşturma ve ana bilgisayara gönderme işlemi neredeyse 2 kat hızlanır. . Ayrıca her gün 120 ücretsiz derleme dakikası kazanırsınız; bu çoğu durumda konteyner oluşturma ihtiyaçlarınızı karşılar.
Daha sonra en önemli performans ölçütü geliyor: Çekme kapsayıcılarını alma veya indirme hızı. Ve eğer bir itme işlemi için harcanan süreyi pek umursamıyorsanız, çekme sürecinin uzunluğunun genel sistem performansı üzerinde ciddi bir etkisi olacaktır. Diyelim ki üç düğümden oluşan bir kümeniz var ve bunlardan biri başarısız oluyor. Google Kubernetes Engine gibi bir yönetim sistemi kullanıyorsanız ölü düğümü otomatik olarak yenisiyle değiştirecektir. Ancak bu yeni düğüm tamamen boş olacak ve çalışmaya başlaması için tüm kaplarınızı buraya sürüklemeniz gerekecek. Çekme işlemi yeterince uzun sürerse kümeniz tüm süre boyunca daha düşük performansta çalışır.
Bunun gerçekleşebileceği birçok durum vardır: bir kümeye yeni bir düğüm eklemek, düğümleri yükseltmek ve hatta dağıtım için yeni bir konteynere geçmek. Bu nedenle çekme çıkarma süresinin en aza indirilmesi önemli bir faktör haline gelir. Küçük bir konteynerin büyük bir konteynerden çok daha hızlı indirildiği inkar edilemez. Bir Kubernetes kümesinde birden fazla kapsayıcı çalıştırıyorsanız önemli ölçüde zaman tasarrufu sağlayabilirsiniz.
Şu karşılaştırmaya bir göz atın: küçük konteynerler üzerindeki çekme işlemi, makinenin gücüne bağlı olarak go:onbuild kullanılarak yapılan aynı işleme göre 4-9 kat daha az zaman alır. Paylaşılan, küçük konteyner tabanlı görüntülerin kullanılması, yeni Kubernetes düğümlerinin dağıtılıp çevrimiçi hale getirilme süresini ve hızını önemli ölçüde hızlandırır.
Güvenlik konusuna bakalım. Daha küçük konteynerler, daha küçük bir saldırı yüzeyine sahip oldukları için büyük olanlardan çok daha güvenli kabul edilir. Gerçekten mi? Google Container Registry'nin en kullanışlı özelliklerinden biri, konteynerlerinizi güvenlik açıklarına karşı otomatik olarak tarama yeteneğidir. Birkaç ay önce hem yerleşik hem de çok aşamalı konteynerler oluşturdum, bu yüzden burada herhangi bir güvenlik açığı olup olmadığına bakalım.
Sonuç şaşırtıcı: Küçük bir kapta yalnızca 3 orta düzeyde güvenlik açığı tespit edildi ve büyük bir kapta 16 kritik ve 376 diğer güvenlik açığı bulundu. Büyük bir konteynerin içeriğine baktığımızda güvenlik sorunlarının çoğunun uygulamamızla alakası olmadığını, hatta kullanmadığımız programlarla ilgili olduğunu görebiliriz. Yani insanlar geniş bir saldırı yüzeyinden bahsederken kastettikleri budur.
Çıkarılan sonuç açıktır: sisteminize gerçek performans ve güvenlik avantajları sağladıkları için küçük kaplar oluşturun.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com