Docker oyuncak mı, değil mi? Yoksa hâlâ doğru mu?

Herkese Merhaba!

Aslında doğrudan konuya girmek istiyorum ama hikayemden biraz bahsetmek daha doğru olur:

Giriş

Sunucu üzerinde ön uç tek sayfa uygulamaları, scala/java ve nodejs geliştirme deneyimi olan bir programcıyım.

Oldukça uzun bir süre (kesinlikle birkaç veya üç yıl), Docker'ın cennetten gelen bir kudret helvası olduğunu ve genel olarak çok harika bir araç olduğunu ve kesinlikle her geliştiricinin onu kullanabilmesi gerektiğini düşünüyordum. Bundan da her geliştiricinin yerel makinesinde Docker'ın kurulu olması gerektiği sonucu çıkıyor. Peki ya benim fikrim, aynı hh'de yayınlanan boş pozisyonlara bakın. Her saniye docker'dan bahsediliyor ve eğer ona sahipseniz, bu sizin rekabet avantajınız olacak 😉

Yolda Docker'a ve ekosistemine karşı farklı tutumları olan birçok insanla tanıştım. Bazıları bunun platformlar arası işlevselliği garanti eden kullanışlı bir şey olduğunu söyledi. İkincisi neden konteynırlarda çalıştırmaları gerektiğini ve bundan ne kadar kâr elde edeceklerini anlamadılar, üçüncüsü hiç umursamadı ve umursamadı (sadece kodu yazıp eve gittiler - onları kıskanıyorum, yol :)

Kullanım nedenleri

Neden docker kullandım? Muhtemelen aşağıdaki nedenlerden dolayı:

• veritabanı başlatılıyor, uygulamaların %99'u bunları kullanıyor
• ön uç dağıtımı ve arka uç için proxy oluşturma için nginx'in başlatılması
• uygulamayı docker imajı içerisinde paketleyebilirsiniz, bu şekilde uygulamam docker'ın olduğu her yerde çalışır, dağıtım sorunu anında çözülür
• kutudan çıktığı gibi hizmet keşfi, mikro hizmetler oluşturabilirsiniz, her bir kapsayıcı (ortak bir ağa bağlı) bir takma ad aracılığıyla diğerine kolayca erişebilir, çok kullanışlı
• Bir kap oluşturmak ve içinde "oynamak" eğlencelidir.

Docker hakkında her zaman hoşlanmadığım şey:

• Uygulamamın çalışabilmesi için sunucuda Docker'ın kendisine ihtiyacım var. Uygulamalarım jre veya nodejs üzerinde çalışıyorsa ve bunların ortamı zaten sunucudaysa buna neden ihtiyacım var?
• (özel) yerel olarak oluşturulmuş görüntümü uzak bir sunucuda çalıştırmak istersem, kendi docker havuzuma ihtiyacım var, kayıt defterinin bir yerde çalışması gerekiyor ve ayrıca https'yi yapılandırmam gerekiyor çünkü docker cli yalnızca https üzerinden çalışıyor. Ah kahretsin... Elbette görüntüyü yerel olarak kaydetme seçenekleri var. docker save ve görüntüyü scp yoluyla göndermeniz yeterli... Ama bu çok fazla vücut hareketi anlamına geliyor. Ayrıca, kendi deponuz görünene kadar bir "koltuk değneği" çözümü gibi görünüyor
• docker-compose. Yalnızca konteynerleri çalıştırmak için gereklidir. Bu kadar. Başka hiçbir şey yapamaz. Docker-compose dosyalarının birçok versiyonu ve kendi sözdizimi vardır. Ne kadar açıklayıcı olursa olsun, belgelerini okumak istemiyorum. Başka hiçbir yerde ihtiyacım olmayacak.
• Bir ekipte çalışırken çoğu kişi Docker dosyasını çok çarpık bir şekilde yazar, nasıl önbelleğe alındığını anlamaz, ihtiyaç duydukları ve ihtiyaç duymadıkları her şeyi görüntüye ekler, Dockerhub'da veya özel bir depoda olmayan görüntülerden miras alır, bazı görüntüler oluşturur. docker-compose veritabanlarına sahip dosyalar ve hiçbir şey devam etmiyor. Aynı zamanda, geliştiriciler gururla Docker'ın harika olduğunu, her şeyin onlar için yerel olarak çalıştığını beyan ediyor ve İK, boş pozisyona önemli bir şekilde şunu yazıyor: "Docker kullanıyoruz ve böyle bir iş deneyimine sahip bir adaya ihtiyacımız var."
• Docker'daki her şeyi yükseltme konusundaki düşünceler sürekli aklıma geliyor: postgresql, kafka, redis. Her şeyin konteynerlerde çalışmaması üzücü, her şeyin yapılandırılması ve çalıştırılması kolay değil. Bu, satıcıların kendisi tarafından değil, üçüncü taraf geliştiriciler tarafından desteklenir. Bu arada şu soru hemen ortaya çıkıyor: Satıcılar ürünlerini Docker'da tutma konusunda endişelenmiyorlar, neden bu, belki bir şeyler biliyorlardır?
• Konteyner verilerinin kalıcılığıyla ilgili soru her zaman ortaya çıkar. ve sonra şunu düşünüyorsunuz, ana bilgisayar dizinini mi bağlamalıyım yoksa bir liman işçisi birimi mi oluşturmalıyım yoksa şu anda olan bir veri taşıyıcısı mı yapmalıyım? deprecated? Bir dizini bağlarsam, konteynerdeki kullanıcının kullanıcı kimliğinin ve kimliğinin, konteyneri başlatan kullanıcının kimliğiyle eşleştiğinden emin olmam gerekir, aksi takdirde konteyner tarafından oluşturulan dosyalar kök haklarıyla oluşturulacaktır. Eğer kullanırsam volume o zaman veriler basitçe bazılarında oluşturulacaktır. /usr/* ve uid ve gid ile ilgili ilk durumda olduğu gibi aynı hikaye olacak. Üçüncü taraf bir bileşeni başlatıyorsanız, belgeleri okumanız ve şu sorunun cevabını aramanız gerekir: "bileşen hangi kapsayıcı dizinlere dosya yazıyor?"

Docker'ı çok uzun süre kurcalamak zorunda kalmam gerçeğini her zaman sevmedim ilk aşamada: Container'ların nasıl başlatılacağını, hangi görsellerden başlatılacağını öğrendim, uzun Docker komutlarına takma adlar içeren Makefile dosyaları oluşturdum. Docker ekosisteminde başka bir araç öğrenmek istemediğim için docker-compose'tan nefret ettim. VE docker-compose up Özellikle hâlâ orada buluşuyor olmaları beni rahatsız ediyordu. build önceden birleştirilmiş görüntüler yerine yapılar. Gerçekten istediğim tek şey, verimli ve hızlı bir şekilde bir ürün yapmaktı. Ancak docker'ın nasıl kullanılacağını bulamadım.

Ansible'la tanışın

Yakın zamanda (üç ay önce), neredeyse her üyesinin Docker'a karşı olumsuz bir tutumu olan bir DevOps ekibiyle çalıştım. Sebeplerden dolayı:

• liman işçisi iptables'ı yönetir (yine de daemon.json'da devre dışı bırakabilirsiniz)
• Docker hatalı ve onu üretimde çalıştırmayacağız
• docker arka plan programı çökerse altyapıya sahip tüm konteynerler buna göre çöker
• liman işçisine gerek yok
• Ansible ve sanal makineler varsa neden docker

Aynı işte başka bir araçla tanıştım - Ansible. Bunu bir kez duymuştum ama kendi başucu kitaplarımı yazmaya çalışmadım. Artık görevlerimi yazmaya başladım ve sonra vizyonum tamamen değişti! Çünkü şunu fark ettim: Ansible'ın aynı docker konteynerlerini, görüntü yapılarını, ağları vb. çalıştırmak için modülleri var ve konteynerler yalnızca yerel olarak değil, aynı zamanda uzak sunucularda da çalıştırılabilir! Zevkim sınır tanımıyordu - NORMAL bir araç buldum ve Makefile ve docker-compose dosyalarımı attım, bunların yerini yaml görevleri aldı. Kod, aşağıdaki gibi yapılar kullanılarak azaltıldı loop, when, vb.

Veritabanları gibi üçüncü taraf bileşenleri çalıştırmak için Docker

Yakın zamanda ssh tünelleriyle tanıştım. Uzak sunucunun bağlantı noktasını yerel bağlantı noktasına "iletmenin" çok kolay olduğu ortaya çıktı. Uzak sunucu, buluttaki bir makine veya VirtualBox'ta çalışan bir sanal makine olabilir. Meslektaşım veya ben bir veritabanına (veya başka bir üçüncü taraf bileşenine) ihtiyacımız olursa, sunucuyu bu bileşenle başlatabilir ve sunucuya ihtiyaç duyulmadığında kapatabiliriz. Bağlantı noktası yönlendirme, liman işçisi konteynerinde çalışan bir veritabanıyla aynı etkiyi verir.

Bu komut yerel bağlantı noktamı postgresql çalıştıran uzak bir sunucuya iletir:

ssh -L 9000:yerelanasistem:5432 [e-posta korumalı]

Uzak bir sunucu kullanmak, ekip geliştirmedeki sorunu çözer. Böyle bir sunucu aynı anda birkaç geliştirici tarafından kullanılabilir; postgresql'i yapılandırmaları, Docker'ı ve diğer incelikleri anlamaları gerekmez. Belirli bir sürümü yüklemek zorsa, uzak bir sunucuda aynı veritabanını Docker'ın kendisine yükleyebilirsiniz. Geliştiricilerin tek ihtiyacı ssh erişimi sağlamaktır!

Yakın zamanda SSH tünellerinin normal bir VPN'in sınırlı işlevselliğine sahip olduğunu okudum! OpenVPN veya diğer VPN uygulamalarını kolayca kurabilir, altyapıyı kurabilir ve geliştiricilerin kullanımına verebilirsiniz. Bu çok havalı!

Neyse ki AWS, GoogleCloud ve diğerleri size bir yıllık ücretsiz kullanım olanağı sunuyor, o yüzden bunları kullanın! Kullanmadığınız zamanlarda kapatırsanız ucuzdurlar. Neden gcloud gibi uzak bir sunucuya ihtiyaç duyacağımı hep merak etmişimdir, öyle görünüyor ki onları buldum.

Yerel sanal makine olarak docker konteynerlerinde aktif olarak kullanılan Alpine'ı kullanabilirsiniz. Peki, ya da makinenin daha hızlı başlatılmasını sağlayacak diğer bazı hafif dağıtımlar.

Sonuç olarak: Veritabanlarını ve diğer altyapı özelliklerini uzak sunucularda veya sanal kutuda çalıştırabilirsiniz ve çalıştırmalısınız. Bu amaçlar için docker'a ihtiyacım yok.

Liman işçisi görüntüleri ve dağıtımı hakkında biraz

Çoktan yazdım Makale Docker görsellerini kullanmanın herhangi bir garanti sağlamadığını aktarmak istedim. Docker görüntüleri yalnızca bir docker kapsayıcısı oluşturmak için gereklidir. Docker görüntüsüne yükseltiyorsanız, docker konteynerlerini kullanacak şekilde yükseltme yapıyorsunuz demektir ve yalnızca bunları kullanacaksınız.

Yazılım geliştiricilerin ürünlerini yalnızca liman işçisi görüntüsünde taşıdığı bir yer gördünüz mü?
Çoğu ürünün sonucu, belirli bir platform için ikili dosyalardır; bunlar yalnızca istenen platformdan devralınan docker görüntüsüne eklenir. Dockerhub'da neden bu kadar çok benzer görselin olduğunu hiç merak ettiniz mi? Örneğin nginx girin, farklı kişilerden 100500 görsel göreceksiniz. Bu insanlar nginx'i kendisi geliştirmediler, sadece resmi nginx'i liman işçisi görüntülerine eklediler ve konteynerleri başlatma kolaylığı için onu kendi yapılandırmalarıyla donattılar.

Genel olarak, birisinin onu docker'da çalıştırması gerekiyorsa, onu basitçe tgz'de saklayabilir, ardından Docker dosyasına tgz eklemesine, istenen ortamdan miras almasına ve uygulamanın kendisini tgz'de değiştirmeyen ek çörekler oluşturmasına izin verebilirsiniz. Docker imajı oluşturacak olan herkes tgz'nin ne olduğunu ve ne çalışması gerektiğini bilecektir. Docker'ı bu şekilde kullanıyorum burada

Özetle: Liman işçisi kayıt defterine ihtiyacım yok, bir tür S3 veya yalnızca Google Drive/dropbox gibi dosya depolama alanı kullanacağım

CI'da Docker

Çalıştığım şirketlerin hepsi aynı. Genellikle bakkaldırlar. Yani, tek bir uygulamaya, tek teknoloji yığınına (belki birkaç veya üç programlama diline) sahiptirler.

Bu şirketler CI sürecinin çalıştığı sunucularında docker kullanıyor. Soru: Neden sunucularınızdaki docker konteynerinde projeler oluşturmanız gerekiyor? Neden sadece derleme için bir ortam hazırlamıyorsun, örneğin, derlemenin gerçekleşeceği sunucuya nodejs, php, jdk, kopya ssh anahtarları vb.'nin gerekli sürümlerini yükleyecek bir Ansible playbook yazmıyorsun?

Artık bunun kendi ayağıma kurşun sıkmak olduğunu anlıyorum çünkü docker izolasyonuyla herhangi bir kazanç getirmiyor. Docker'da CI ile karşılaştığım sorunlar:

• oluşturmak için yine bir liman işçisi görüntüsüne ihtiyacınız var. bir görüntü aramanız veya kendi docker dosyanızı yazmanız gerekir.
• Docker görüntüsüne yazmak istemediğiniz gizli veriler olan bazı ssh anahtarlarını %90 oranında iletmeniz gerekir.
• kapsayıcı oluşturulur ve ölür, onunla birlikte tüm önbellekler de kaybolur. bir sonraki yapı tüm proje bağımlılıklarını yeniden indirecektir; bu da zaman alıcı ve etkisizdir ve vakit nakittir.

Geliştiriciler liman işçisi konteynerlerinde proje oluşturmazlar (Bir zamanlar onun hayranıydım, gerçekten geçmişte kendime üzülüyorum xD). Java'da birden fazla sürüme sahip olmak ve bunları tek bir komutla şu anda ihtiyacınız olan sürümle değiştirmek mümkündür. Nodejs'de de durum aynı, nvm var.

Aviator apk

Docker'ın çok güçlü ve esnek bir araç olduğuna inanıyorum, bu onun dezavantajıdır (kulağa tuhaf geliyor, evet). Onun yardımıyla şirketler kolayca ona bağlanıp ihtiyaç duyulan ve ihtiyaç duyulmayan yerde kullanabilirler. Geliştiriciler konteynerlerini ve bazı ortamlarını başlatır ve ardından bunların tümü sorunsuz bir şekilde CI'ya ve üretime akar. DevOps ekibi bu kapsayıcıları çalıştırmak için bir tür kod yazıyor.

Docker'ı yalnızca üzerinde kullan en son İş akışınızdaki aşamayı başlangıçta projeye sürüklemeyin. İş problemlerinizi çözmez. O ancak sorunları BAŞKA bir seviyeye taşıyacak ve kendi çözümlerini sunacak, siz ikili iş yapacaksınız.

Docker'a ihtiyaç duyulduğunda: Docker'ın belirli bir süreci optimize etmede çok iyi olduğu ancak temel işlevsellik oluşturmada çok iyi olmadığı sonucuna vardım.

Hala docker kullanmaya karar verirseniz, o zaman:

• son derece dikkatli ol
• geliştiricileri docker kullanmaya zorlamayın
• kullanımını tek bir yerde yerelleştirin, tüm Dockefile ve docker-compose depolarına yaymayın

Not:

• yakın zamanda karşılaştım toptancı Ansible ile çok iyi çalıştığını ve görsel oluşturma sürecini birleştirmenize izin verdiğini söylüyorlar (liman işçisi görüntüsü dahil)
• ayrıca liman işçisi hakkında, ilginç bir makale

Okuduğunuz için teşekkür ederim, işlerinizde şeffaf kararlar ve verimli çalışma günleri dilerim!

Kaynak: habr.com