g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Yazar | Yitian Coder

Editör | Tu Min

Daha önce, bulut yerelinin (https://blog.csdn.net/weixin_38748858/article/details/103514909) genişletilmiş anlamını paylaşıyorduk, yani geliştirme ortamı aynı zamanda bir bulut ortamıdır, böylece geliştirme ortamı ve üretim ortamının tutarlılığı garanti altına alınabilir. Son dağıtımın sorunsuz ilerlemesini sağlayın. Bu makale, bulutta yerel geliştirme ortamını belirli örneklerle tartışır. Geliştirme süreci temel olarak kodlama, program dağıtımı ve hata ayıklamayı içerir. Verimliliği artırmanıza yardımcı olmak için her bağlantının ilgili araçlara ihtiyacı vardır. Bir geliştirme bulut ortamının nasıl oluşturulacağına ve bulut ortamında geliştirme verimliliğini artırmanıza yardımcı olabilecek araçlara bir göz atalım.

Geliştirme IDE

Önceki IDE yalnızca uygulama geliştirmeyi destekler, ancak bulut yerel, aynı anda geliştirme ortamının (kapsayıcı) geliştirilmesini gerektirir.İdeal olarak, bir IDE her ikisini de destekleyebilir. Go dilini kullanıyorum ve tercih edilen IDE, k8'leri destekleyen Goland (yani IDEA IntelliJ), sadece ihtiyacınız olan indir Bir eklenti yapacak. K8'lerin Otomatik Tamamlama gibi işlevleri destekler. Aşağıdaki şekilde gösterildiği gibi, hem uygulamaları hem de k8'leri destekleyen bir IDE'ye sahipsiniz.

Ancak k8s için desteğinin çok ilkel olduğunu ve k8s nesneleri arasındaki iç bağlantıyı anlayamadığını söylemeliyim. Ek olarak, k8s yapılandırma dosyasının format konusunda katı gereksinimleri vardır.Boşluklar yanlışsa veya format hizalı değilse, dağıtım sırasında bir hata raporlanacaktır. Goland, formatı kontrol etme işlevine sahiptir.Bir sorun varsa, bir hata bildirir, ancak her hata bulunamaz. Başka bir deyişle, herhangi bir hata bildirmediğinde formatın doğru olup olmadığı kesin değildir. Bu birkaç kez oldu, IDE bir hata bildirmedi, ancak dağıtım sırasında bir sorun vardı.

IntelliJ'in k8s desteği için lütfen IntelliJ IDEA 2018.1: Kubernetes desteği (https: //blog.jetbrains .com / fikir / 2018/03 / intellij-idea-2018-1-kubernetes-support /).

Ortam kurulumu

Tuning k8s Minikube üzerinde yapılır ve Minikube Linux sanal makineye yüklenir. Bu, hata ayıklamayı kolaylaştırmak için ana bilgisayar ile geliştirme ortamının sanal makinesi arasında dosya paylaşımını gerektirir. Geliştirme ortamım Windows ve VirtualBox sanal makineyi Windows'a kurdum ve ayrıca VirtualBox'ı yönetmek için bir arayüz olarak Vagrant'ı (sanal makineleri yönetmek için bir yazılım) kurdum.

Program paylaşımı

Go uygulamam Windows'ta "C: codesrcgithub" .com "Jfeng45k8sdemo" dizini altında, ana bilgisayarın dizinini Vagrant aracılığıyla sanal makineye bağlayabilirsiniz, böylece IDE üzerindeki k8s yapılandırma dosyasını her değiştirdiğinizde, ek senkronizasyon olmadan doğrudan sanal makineye alabilirsiniz.

Vagrant'taki konfigürasyon şu şekildedir:

config.vm.synced_folder "C: / code / src / github .com / jfeng45 "," / ev / serseri / jfeng45 ", İD: "jfeng45"

ağ paylaşımı

Ana bilgisayar (dizüstü bilgisayar) ve sanal makine arasında, sanal makineye erişmek için esas olarak ana bilgisayardan karşılıklı erişim sağlamaktır. Vagrant kullanıyorum, bu yüzden onu Vagran'ın yapılandırma dosyasında (Vagrantfile) yapılandırmam gerekiyor. Ağı yapılandırmanın farklı yolları var: Çok esnek bir yol olan özel bir ağ yapılandırıyorum. Yapılandırma yöntemi, ana bilgisayar ve sanal makine için sabit bir IP adresi ayarlamaktır, böylece iki yönlü karşılıklı ziyaretler yapılabilir.

Vagrant konfigürasyon komutları:

"Config.vm.network" private_network ", ip:" 192.168.50.4 "

Veritabanı paylaşımı

K8'leri yapılandırırken, veritabanı genellikle bir hizmet olarak ayarlanır. Ana makinede k8s veritabanına erişebiliyorsanız, veritabanını önceden test edebilir ve veritabanı sorunlarını olabildiğince erken keşfedebilirsiniz. Sanal makine ile ana bilgisayar arasındaki ağ bağlandıktan sonra, veritabanına ana bilgisayardan doğrudan erişilebilir.

Ortam yapılandırmasıyla ilgili ayrıntılar için lütfen "MySQL (Bölüm 1) oluşturarak önemli k8s (Kubernetes) kavramlarına hakim olma: Ağ ve Kalıcı Birim" (https://blog.csdn.net/weixin_38748858/article/details/102514721) bölümüne bakın

Gelişme süreci

Geliştirme süreci genellikle böyledir. Önce yerel IDE'ye (uygulama ve k8s kodu dahil) kod yazarsınız ve kod yerel sabit diskte depolanır. Tamamlandıktan sonra, sanal makine ortamına girersiniz, k8s kümesini ve uygulama kodunu dağıtırsınız ve ardından sonuçları test etmek için k8s kümesinde kodu çalıştırırsınız. Bu döngüyü tekrarlayın.

İşlem örneği

Süreci bir örnekle açıklıyoruz. Kodu yerel olarak yazdıktan sonra, k8s programında hata ayıklamak gerekir. Sanal makineyi önce Vagrant ile başlatın ve ardından Minikube'u başlatın:

sudo minikube başlangıcı

Program yapısı

Yukarıdaki, programın dizin yapısıdır. "Cmd" dizini ana programdır, "config" dizini program yapılandırmasından sorumludur, "veri hizmeti" veri erişim katmanıdır, "model" etki alanı modeli katmanıdır ve "günlükler" dizini günlükleri depolamak içindir. "Komut Dosyası", program dağıtımıyla ilgili tüm dosyaları içerir. Bunlar arasında, "veritabanı" veritabanı betiğidir ve "kubernetes", daha sonra ayrıntılı olarak açıklanacak olan k8s'in tüm yapılandırma dosyalarıdır.

Yukarıdaki, k8s yapılandırma dosyalarının dizin yapısıdır. En dıştaki iki dosya olan "k8sdemo-config.yaml" ve "k8sdemo-secret.yaml" paylaşılan dosyalardır, bu nedenle en dış düzeye yerleştirilirler. Arka uç programının ve veritabanının yapılandırma dosyalarını sırasıyla depolamak için başlıca iki alt dizin "arka uç" ve "veritabanı" vardır. Dahili yapı benzerdir, üç "yaml" dosyası vardır, "backend-deployment.yaml" dağıtım yapılandırma dosyasıdır, "backend-service.yaml" hizmet yapılandırma dosyasıdır ve "backend-volume.yaml" kalıcı birim yapılandırmasıdır Dosya. ".Sh", k8s nesnelerini oluşturmak için kullanılan k8s komutudur. "Arka uç" dizininde ayrıca arka uç uygulamasının Docker görüntüsünü depolamak için bir "docker" alt dizini bulunur Veritabanı görüntü dosyası doğrudan Docker kitaplığından alınır, bu nedenle başka bir görüntü dosyası oluşturmaya gerek yoktur.

K8'lerin temel konsepti için lütfen "Örnekler aracılığıyla k8'lerin (Kubernetes) temel konseptini hızlı bir şekilde kavrayın" (https://blog.csdn.net/weixin_38748858/article/details/102132544) bölümüne bakın.

Uygulamaları ve k8'leri dağıtın ve hatalarını ayıklayın

Programımızın "k8sdemo-database-service" ve "k8sdemo-backend-service" olmak üzere iki servisi vardır. Diğer servislere bağlı olmadığı için önce "k8sdemo-veritabanı-servisini" konuşlandırmalıyız. Bununla birlikte, bazı nesneler paylaşılır ve önce hata ayıklanması gerekir. Unutulmaması gereken bir nokta, k8s nesneleri birbirine bağlı olduğundan, onları oluştururken sırayla oluşturmanız gerektiğidir. Yerleştirme sırası şu Gizli ... > ConfigMap- > Ses- > Dağıtım > Hizmet.

Paylaşılan nesneleri dağıtın:

cd / home / vagrant / jfeng45 / k8sdemo / script / kubernetes Kubectl uygulama ly -f k8sdemo-config.yaml Kubectl uygulama ly -f k8sdemo-secret.yaml

Oluşturmayı kontrol edin:

kubectl configMap'i tanımlar kubectl sırrı tanımlar

Veritabanı hizmetini dağıtın:

cd / home / vagrant / jfeng45 / k8sdemo / script / kubernetes / veritabanı Kubectl uygulama ly -f veritabanı-volume.yaml Kubectl uygulama ly -f veritabanı-deployment.yaml Kubectl uygulama ly -f veritabanı-service.yaml

Veritabanı oluşturulduktan sonra, sanal makine üzerindeki kitaplığa doğrudan erişmek için IDE'deki programı kullanabilirsiniz, bu daha rahattır. Ancak ortam değişkenlerini ayarlamanız gerekir. ConfigMap tarafından k8s'de ayarlanır ve Windows'ta ayrı olarak ayarlanması gerekir Komut "windowsEnv.bat" içindedir. İçerik aşağıdaki gibidir:

setx MYSQL_ROOT_PASSWORD kökü setx MYSQL_USER_NAME dbuser setx MYSQL_USER_PASSWORD dbuser setx MYSQL_DATABASE service_config setx MYSQL_HOST 192.168.50.4 setx MYSQL_PORT 30 30 6

Bir uygulama görüntüsü oluşturun:

cd / ev / serseri / jfeng45 / k8sdemo / docker build -f ./script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend -t k8sdemo-backend.

Arka uç hizmetleri dağıtın

cd / home / vagrant / jfeng45 / k8sdemo / script / kubernetes / arka uç Kubectl uygulama ly -f arka uç-volume.yaml Kubectl uygulama ly -f arka uç-deployment.yaml Kubectl uygulama ly -f arka uç-service.yaml

Kapsayıcıda oturum açın ve sonuçları görüntülemek için programı çalıştırın:

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / backend $ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k - / bin / sh ~ # ./main.exe zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "veritabanına bağlan" zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "dataSourceName: dbuser: dbuser @ tcp (k8sdemo-veritabanı-hizmeti: 3 30 6) / service_config? Charset = utf8 " zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "Tümünü Bul" zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = " yaratıldı = 2019-10-21 " zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "kullanıcı bul: {1 Tony IT 2019-10-21}" zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "kullanıcı listesini bul:" zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "kullanıcı lst:"

Yukarıdaki adımlardaki k8s parçasının, uygulama her değiştirildiğinde çalıştırılmasına gerek yoktur, genellikle sadece değiştirilmiş olan kısım. Genel olarak konuşursak, programın Docker görüntüsü değiştiği için yalnızca dağıtım (Dağıtım) değiştirilecektir. Öyle bile olsa, bir hata ayıklamayı tamamlamak için birçok adım vardır.

K8'lerin temel kavramları için lütfen "Örnekler aracılığıyla k8'lerin (Kubernetes) temel kavramlarını hızlı bir şekilde kavrayın" (https://blog.csdn.net/weixin_38748858/article/details/102132544) bölümüne bakın.

Özet:

Yukarıdaki süreçten, yerel bulut ortamında geliştirme ve hata ayıklamanın oldukça külfetli olduğu görülebilir.Ana makine ile sanal makine arasında geçiş yapmanız ve aynı zamanda uygulama ve k8'lerin hatalarını ayıklamanız gerekir.Ortada çok fazla manuel çalışma var. İşlem, yazılacak çok sayıda komut var, bunu nasıl basitleştirebiliriz?

Dümen

K8'lerin acı noktalarından biri, birçok bileşene (dağıtım, servis, depolama hacmi vb.) Sahip olmasıdır, bunların her biri komutlar yazarak hata ayıklaması gerekir, özellikle bir sorun olduğunda, orijinali defalarca silmeniz ve yeni bir tane oluşturmanız gerekir. Miğfer bu acı noktayı çözdü. Helm, Java'daki Maven ve Go'daki "Go Module" gibi en popüler k8s paket yönetim aracıdır. Temel kavramlarından biri "Harita" dır. Bununla k8'lerin çeşitli bölümlerini bir bütün olarak yönetebilirsiniz, böylece Çok İş yükünü azaltın. Hata ayıklamanın erken aşamasında, karmaşıklığı azaltmak için her bir parçada ayrı ayrı hata ayıklamaya devam edebilirsiniz. Ancak başarılı olduktan sonra, onu bir bütün olarak çalıştırabilirsiniz. Çok Basitleştirilmiş operasyon. Helm'in bir başka rolü de K8s konfigürasyonunun sürümünü yönetmektir.

Helm dosya yapısı

Grafikteki çok önemli bir kavram, Go dili şablonu olan şablondur. Şablon, programlama mantığının eklendiği k8s dosyasıdır. Bu şablon dosyaları kullanıldığında, önce analiz edilmeleri gerekir ve içlerindeki program mantığı karşılık gelen kodlara dönüştürülür ve sonunda k8s yapılandırma dosyası oluşturulur.

Yukarıdakiler, Helm tarafından otomatik olarak oluşturulan çizelge dizin yapısıdır. Helm'deki her öğeye aşağıdaki bileşenlerden oluşan bir çizelge adı verilir:

• "Chart.yaml": Bu grafiğin temel bilgileri saklanır,

• "values.yaml": Şablonda kullanılacak sabitleri tanımlayın.

• "Şablon" dizini: En önemlileri sırasıyla dağıtım ve hizmet dosyaları olan "deployment.yaml" ve "service.yaml" olan tüm şablon dosyalarını içerir. "Helpers.tpl" değişkenleri tanımlamak için kullanılır, "giriş". "yaml" ve "serviceaccount.yaml", burada geçici olarak yararsız olan sırasıyla harici arayüz ve hizmet hesabıdır. "NOTES.txt" bir yorum dosyasıdır.

• "Grafikler" dizini: Bu grafiğin bağlı olduğu tüm alt grafikleri depolar.

Grafik tasarımı

Şimdi Helm'in grafik tasarımını göstermek için bir örnek kullanıyoruz. Bu örnek, üç katmana sahip bir mikro hizmet uygulamasıdır: ön uç, arka uç ve veritabanı.

K8'lerde her katman, çeşitli yapılandırma dosyalarına sahip ayrı bir hizmettir. Helm'in avantajı, bu farklı hizmetlerin birlikte yönetmek ve hata ayıklamak için bir Grafikte birleştirilmesidir, bu çok daha uygundur. Bir grafik oluşturmak için aşağıdaki komutu yazın, burada "k8sdemo" grafiğin adıdır Bu isim çok önemlidir.Hizmet adı ve etiketinin tamamı onun tarafından oluşturulur.

dümen k8sdemo oluştur

Bundan sonra, sistem daha önce bahsedilen grafik dizin yapısını otomatik olarak oluşturacaktır. Daha sonra üretilen dosyaları değiştirmektir.

Yukarıdaki son grafik dizin yapısı diyagramıdır. "Grafik" genel katalogdur, "k8sdemo", "k8sdemo-arka uç", "k8sdemo-veritabanı" olmak üzere üç alt dizin vardır, her biri bir hizmete karşılık gelir, her hizmet, hata ayıklaması yapılabilen ve ayrı ayrı dağıtılabilen bağımsız bir çizelgedir. Arasında bağımlılıklar da olabilir. Bunların arasında, "k8sdemo" ana grafiktir ve ayrıca bir ön uç hizmetidir. "Çizelgeler" dizini, bağlı olduğu diğer iki hizmeti içerir. "K8sdemo-arka uç" arka uç hizmetidir ve "k8sdemo-veritabanı" veritabanı hizmetidir.

K8sdemo'yu yükleyin:

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / chart $ helm yükseltme k8sdemo ./k8sdemo "K8sdemo" sürümü yükseltildi. H uygulama y Helming! ADI: k8sdemo SON YERLEŞTİRİLEN: 29 Kasım Cum 01:28:552019 NAMESPACE: varsayılan DURUM: dağıtıldı REVİZYON: 2 NOTLAR: 1. uygulama şu komutları çalıştırarak lisans URL'si: dışa aktar NODE_PORT = $ (kubectl get --namespace varsayılan -o jsonpath = "{. spec.ports.nodePort}" hizmetleri k8sdemo) dışa aktar NODE_IP = $ (kubectl get nodes --namespace default -o jsonpath = "{. items.status.addresses.address}") Eko http : // $ NODE_IP: $ NODE_PORT

Kapsül adını alın:

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / chart $ kubectl pod al İSİM HAZIR DURUM YENİDEN BAŞLATMA YAŞI k8sdemo-74cb7b997c-pgcj41/1 Çalışıyor 033s k8sdemo-arka uç-5cd9d79856-dqlmz 1/1 Koşu 033s k8sdemo-database-85855485c6-jtksb 1/1 Çalışıyor 033s k8sdemo-jenkins-deployment-675dd574cb-r57sb 1/1 Koşu 323d

Test etmek için programı çalıştırın:

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / chart $ kubectl exec -ti k8sdemo-arka uç-5cd9d79856-dqlmz - / bin / sh ~ # ./main.exe zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = "veritabanına bağlan" zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = "dataSourceName: dbuser: dbuser @ tcp (k8sdemo-veritabanı-hizmeti: 3 30 6) / service_config? Charset = utf8 " zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = "Tümünü Bul" zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = " yaratıldı = 2019-10-21 " zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = "kullanıcı bul: {1 Tony IT 2019-10-21}" zaman = "2019-11-27T07: 03: 03Z" level = hata ayıklama msg = "kullanıcı listesini bul:" zaman = "2019-11-27T07: 03: 03Z" seviye = hata ayıklama msg = "kullanıcı lst:" ~ #

Yukarıdan da görülebileceği gibi, Helm kullanıldıktan sonra, Çok K8'lerin dağıtımını ve hata ayıklama sürecini basitleştirir. Tüm k8s nesneleri tek adımda konuşlandırılabilir.

Ayrıntılar için lütfen Helm3 ile Çok Katmanlı Mikro Hizmetler Oluşturma konusuna bakın: https://blog.csdn.net/weixin_38748858/article/details/103311973

Otomatik hata ayıklama aracı

Helm, k8'lerin dağıtım sorununu çözer, ancak programı değiştirdikten sonra, dağıtmak için Docker görüntüsünü güncellemeniz gerekir. Dağıtımdan sonra sonuçları test etmeniz ve karşılaştırmanız gerekir. Hala çok sayıda manuel işlem var. Bu görevleri otomatik olarak tamamlayabilen araçlar var mı? Gerçekten bu tür araçlar var ve daha pek çoğu var ve bunların işlevleri aynı değil. Görece yararlı olan ve tüm dağıtım ve hata ayıklama sürecini otomatikleştiren bir araç türü vardır. İşlevleri ve süreçleri genel olarak böyledir.

Program değişikliklerini otomatik olarak algılar, bulunduğunda otomatik olarak bir Docker görüntüsü oluşturur, ardından yeni görüntü dosyasını k8s kümesine dağıtmak için k8s dağıtım dosyasını çağırır, ardından test için test programını çağırır ve sonuçları konsolda görüntüler. Tüm süreç, tek bir komut satırı yazmanızı gerektirmez, tümü otomatik olarak yürütülür. Bu, manuel işlemleri tamamen ortadan kaldırır ve tüm sürecin otomatik olarak yürütülmesini sağlar. Programın bir satırını her değiştirdiğinizde test etmek istemediğinizi, ancak ihtiyaç duyduğunuzda test etmek istemediğinizi söyleyebilirsiniz. Bu işlev bazı araçlarda da yapılandırılabilir.Bir tetikleyici yapılandırabilirsiniz ve yukarıdaki işlem yalnızca tetiklendiğinde otomatik olarak tamamlanacaktır.

Skaffold yapılandırma dosyası:

Şimdi özellikle açıklamak için bir örnek kullanacağız, kullanılan araç Skaffold'dur. Skaffold'un ana kısmı, projenin kök dizininde saklanan "skaffold.yaml" adlı bir yapılandırma dosyasıdır. Docker görüntüsünün dosya adı, k8'lerin dağıtım dosyası vb. Gibi Skaffold tarafından ihtiyaç duyulan bilgiler vardır.

apiVersion: skaffold / v1 tür: Yapılandırma meta veriler: isim: k-sdemo inşa etmek: eserler: -image: k8sdemo-arka uç bağlam :. liman işçisi: dockerfile: script / kubernetes / arka uç / docker / Dockerfile-k8sdemo-arka uç dağıtmak: kubectl: manifestolar: -script / kubernetes / arka uç / arka uç-deployment.yaml -script / kubernetes / arka uç / arka uç-service.yaml

Yukarıdakiler bu dosyadır, k8s'in yapılandırma dosyasına çok benzer ve türü "Config" dir. İçeride iki ana bölüm vardır, biri projenin Docker imajını oluşturmaktan sorumlu "build", diğeri ise oluşturulan imajı k8'lere dağıtmaktan sorumlu "deploy".

Skaffold, otomatik olarak temel bir yapılandırma dosyası oluşturmanıza yardımcı olabilir. "Skaffold init" yazabilirsiniz, size bazı sorular sorar ve cevaplarınıza göre otomatik olarak "skaffold.yaml" dosyasını oluşturur. Oluşturulduktan sonra, onu gerektiği gibi değiştirebilirsiniz. Burada daha önemli olan şey, ayna dosyası ve k8s dağıtım dosyasına yapılan referanstır. Bu dosyaları daha önce oluşturduysanız, yeniden kullanabilirsiniz.

Skaffold'u çalıştırın:

"Skaffold.yaml" dosyasını oluşturduktan sonra aşağıdaki komutu "skaffold dev" yazın, sistem "skaffold.yaml" çalıştıracak, k8s dağıtacak ve program değişikliğini izlemeye başlayacaktır. Çıktı aşağıdaki gibidir:

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo $ skaffold dev UYARI Minikube docker env alınamadı, yerel docker daemon'a geri dönüyor: minikube tr v: Çalıştırma: stdout, stderr: * İzlenecek dosyalar listeleniyor ... -k8sdemo-arka uç Etiket oluşturuluyor ... -k8sdemo-arka uç- > k8sdemo-arka uç: 05894ca-kirli Önbellek kontrol ediliyor ... -k8sdemo-arka uç: Bulunamadı. Yerel docker daemon kullanılarak bağlam bulundu. Bina ... Docker daemon 534.5kB'ye derleme bağlamı gönderme Adım 1/13: golang'DAN: inşaatçı olarak en son --- > dc7582e06f8e Adım 2/13: WORKDIR / uygulama --- > Önbelleği kullanma --- > d5d126eaa528 Adım 3/13: KOPYALA go.mod go.sum ./ --- > Önbelleği kullanma --- > 6ed4 30 911953 Adım 4/13: RUN go mod download --- > Önbelleği kullanma --- > bfb89c8b352b Adım 5/13: KOPYALA .. --- > 6c1f89974762 Adım 6/13: WORKDIR / uygulama / cmd --- > D36e8a412aae'de çalışıyor --- > 9f7f92349811 Adım 7/13: RUN go build -o main.exe --- > 31ff6408dfda'da çalışıyor --- > 31d84d0c860a Adım 8/13: Alpinden: en son --- > 965ea09ff2eb Adım 9/13: RUN apk --no-cache ca-sertifika ekle --- > Önbelleği kullanma --- > a27265887a1e Adım 10/13: WORKDIR / root / --- > Önbelleği kullanma --- > b9c048c97f07 Adım 11/13: ÇALIŞTIR mkdir / lib64 ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2 --- > Önbelleği kullanma --- > 95a2b77e3e0a Adım 12/13: COPY --from = oluşturucu / uygulama /cmd/main.exe. --- > Önbelleği kullanma --- > 5ef8db6e073a Adım 13/13: CMD exec / bin / sh -c "trap: TERM INT; (doğruyken; 1000 uyku yap; tamam) ve bekle" --- > Önbelleği kullanma --- > 6f3e1f751ac66f3e1f751ac6 başarıyla oluşturuldu Başarıyla etiketlendi k8sdemo-backend: 05894ca-dirty Dağıtımda kullanılan etiketler: -k8sdemo-arka uç- > k8sdemo-arka uç: 6f3e1f751ac6ad3c39092a9 30 8f9a6e1d5e087da275349aa3719344785b26f1a yerel resimlere özet olarak referans verilemez. vardır bunun yerine benzersiz bir kimlikle etiketlenmiş ve referans verilmiş Dağıtıma başlanıyor ... -dağıtım. uygulama s / k8sdemo arka uç dağıtımı yaratıldı -hizmet / k8sdemo-arka uç-hizmeti yaratıldı Değişiklikler izleniyor ...

Bir test programınız varsa sonuçları konsola yazdırabilirsiniz. Bir test programım yok, programı çalıştırmak ve sonuçları kontrol etmek için Pod'a giriş yapmam gerekiyor.

Kapsül adını alın

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / arka uç $ kubectl pod al İSİM HAZIR DURUM YENİDEN BAŞLATMA YAŞI k8sdemo-74cb7b997c-8hpdq 1/1 Çalışıyor 111d k8sdemo-backend-5cd9d79856-nwlcl 1/11 11d Çalışıyor k8sdemo-backend-deployment-57bcd56f7d-26p5k 1/1 Çalıştırma 014s k8sdemo-database-85855485c6-vnsp41/11 11d Çalıştırılıyor k8sdemo-jenkins-deployment-675dd574cb-r57sb 1/1 Koşu 536d

Pod'a giriş yapın ve programı çalıştırın

vagrant @ ubuntu-xenial: ~ / jfeng45 / k8sdemo / script / kubernetes / backend $ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k - / bin / sh ~ # ./main.exe zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "veritabanına bağlan" zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "dataSourceName: dbuser: dbuser @ tcp (k8sdemo-veritabanı-hizmeti: 3 30 6) / service_config? Charset = utf8 " zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "Tümünü Bul" zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = " yaratıldı = 2019-10-21 " zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "kullanıcı bul: {1 Tony IT 2019-10-21}" zaman = "2019-12-10T06: 23: 45Z" level = hata ayıklama msg = "kullanıcı listesini bul:" zaman = "2019-12-10T06: 23: 45Z" seviye = hata ayıklama msg = "kullanıcı lst skaffold:"

Skaffold hakkında daha fazla bilgi için lütfen Skaffold ile Çalışma konusuna bakın (https://skaffold.dev/docs/workflows/)

Otomatik hata ayıklama araçlarının karşılaştırması:

Dört popüler otomatik hata ayıklama aracı vardır, bunlar "Taslak", "Skaffold", "Bahçe" ve "Eğim" dir.

Bahçe: Test ettiğim ilk şey "Bahçe" idi çünkü çok güçlü. Ancak testten sonra, çok esnek olmadığı ve proje dizin yapısı için özel gereksinimlere sahip olduğu görüldü. Örneğin, projenizde üç mikro hizmet varsa, genel bir proje oluşturacaktır, üç mikro hizmetin her biri bir alt projedir, her alt projenin bir "Bahçe" mikro hizmet yapılandırma dosyasına ihtiyacı vardır ve toplam proje de bir yapılandırmaya ihtiyaç duyar Dosya ve dosya adı ve konumu sabittir. Bu, genel program yapısını yapılandırmayı ve bunlarla çakışmayı çok zahmetli hale getirir. "Bahçe" tasarım fikri iyidir, geliştirme ve dağıtımı birleştirmek için bir araç kullanmak ister. Bununla birlikte, geliştirme ve dağıtım arasındaki büyük fark nedeniyle, birleştirmenin sonucu belirsizdir. Verdiği örnekler de çok basit örnekler, daha karmaşık projelere uygulandığında çok sakıncalı olacağını düşünüyorum.

Bahçe ayrıntıları için lütfen Giriş bölümüne bakın: https://docs.garden.io/

Eğim: "Eğim" benim ikinci testim, çok esnek ve güçlü görünüyor. Ancak koştuktan sonra Minikube'ye bağlanırken bir sorun çıktı ve bağlanamadı. Resmi kurulum belgesinde verilen varsayılan k8s kümesi Microk8s'dir. Belgeleri de Minikube'u desteklediğini söylüyor, ancak hangi ayarların yapılması gerektiğini açıklamıyor.Ayarlar olmadan doğrudan bağlanabilir gibi görünüyor.Minikube'imde neden bir sorun var bilmiyorum. Elbette, başladığımda bağlantı sorunlarına neden olan "minikube start --vm-driver = none" kullanmam da mümkün. Biraz zaman ayırıp dikkatlice incelersem problem çözülmeli diye düşünüyorum ama Minikube'ye bağlanmak tüm sürecin ilk adımı ... Minikube ile ortaya çıktığında kendimi biraz daha az güvende hissettirdi, bu yüzden bırakmaya karar verdim.

Eğim ayrıntıları için lütfen Eğitim: İlk 15 Dakika'ya bakın: https://docs.tilt.dev/tutorial.html

İskele: Bu, test ettiğim üçüncü araç. Çok güçlü ve esnektir, bazı problemlerle karşılaşılmasına rağmen hızlı bir şekilde çözülmüştür. Bu yüzden Skaffold'dan çok memnunum. Bu erişilebilir değil. Bunu GitHub sürümünde bulabilirsiniz indir Yürütülebilir dosya ve ardından onu "/ usr / local / bin / skaffold" dizinine kopyalayın.

Taslak: Taslağı test etmedim. Taslak artık korunmuyor ve geliştiricilerinin başka görevleri var ve geliştirmeye devam etmeyi bıraktı. Taslağın kullanımı daha kolay olmalı, ancak yeterince güçlü olmamalıdır.

Genel Yorumlar: Genel olarak Skaffold'dan çok memnunum, öyle Çok Hata ayıklama sürecini basitleştirdi. Ancak bu tür bir aracın düşündüğüm kadar mükemmel olmadığını düşünüyorum. Program her değiştirildiğinde görüntünün yeniden oluşturulması gerektiğinden, bu süreç çok yavaştır. Elbette, yerel bir ayna kitaplığı oluşturmak gibi birçok şekilde optimize edebilirsiniz. Ek olarak, bu tür araçların kendileri de aşağıdaki gibi optimizasyon önlemlerine sahiptir: indir Kütüphanenin optimizasyonu. Ancak genel olarak hala yerel çevre ile karşılaştırılamaz.

Bu araçların ayrıntılı bir karşılaştırması için Kubernetes'te yerel geliştirme için nihai kılavuza bakın: Draft - Skaffold - Garden.io (https://codefresh.io/howtos/local-k8s-draft-skaffold-garden/) ve Yerel Kubernetes Tilt.dev ile geliştirme (https://codefresh.io/kubernetes-tutorial/local-kubernetes-development-tilt-dev/).

Geliştirme modeli

Bulutta yerel geliştirme modunda, projenin çalışan ortamını iki bölüme ayırabilirsiniz. Bir kısım, bulut ortamında (yani, k8s kümesi) dağıtılan, projenin çağırması gereken hizmetler ve kaynaklardır. Helm'i, bu projenin çağırması gereken tüm k8s hizmetlerini (veritabanı hizmetleri dahil) içeren bir grafik oluşturmak için kullanabilir ve ardından bu grafiği k8s kümesine dağıtabilirsiniz Programın bu kısmı daha az sıklıkla değişir. Bu hizmetlerdeki bazı kodlar değiştiğinde, sadece grafiği yeniden dağıtmanız gerekir. Diğeri ise projenin kodu ve çalışma ortamıdır Programın bu kısmı sık sık değişir. Bu bölüm k8'lerde veya yerel ortamda çalıştırılabilir. Farkı, farklı geliştirme modelini belirler.

Saf bulut yerel geliştirme modeli:

Bu modda, IDE ve kodun yerel olması dışında, diğer her şey bulut ortamındadır. Proje kodu değiştirildikten sonra, yeni bir Docker görüntü dosyası oluşturmanız, ardından görüntüyü k8s kümesine dağıtmanız ve k8s kümesinde hata ayıklamanız gerekir. Bu görevi gerçekleştirmek için daha önce bahsedilen otomatik hata ayıklama araçlarını kullanabilirsiniz. Avantajı, geliştirme ortamının üretim ortamıyla tamamen uyumlu olmasıdır, bu da üretim ortamında dağıtım sırasında sürprizlerin olmamasını sağlar. Dezavantajı, hata ayıklama verimliliğinin biraz daha düşük olmasıdır. Buluta hem IDE hem de kod koymak istiyorsanız, yerel olarak bir tane olduğu sürece bu da mümkündür. Müşteri Sadece gelin ve ziyaret edin. Şu anda, saf bir bulut geliştirme ortamıdır, ancak sembolik önemi daha büyüktür ve gerçek çalışma üzerinde fazla bir etkisi yoktur.

Hibrit geliştirme modeli:

Bu modda, proje yerel olarak hata ayıklanır ve bağlı olduğu diğer mikro hizmetler bulut ortamında (sanal makinede k8'ler) dağıtılır. Sanal makinenin yerel ortamı ve ağı bağlı olduğundan yerel ortamda çalışan kod sanal makine üzerindeki mikro hizmetlere erişebilir. Veritabanı da aynıdır, ayrıca k8s kümesine de dağıtılır, onu bir hizmet olarak kabul edebilir ve yerelden geçebilirsiniz. Müşteri Veritabanındaki verilere erişin. Şu anda, veritabanının fiziksel konumu ister bulutta ister yerel olarak sizin için şeffaftır. Projenin kodu değiştirildiğinde, projeyi yerel olarak çalıştırır ve hatalarını ayıklarsınız. Bir web sunucusuna ihtiyacınız varsa, Go gibi bazı diller için sorun değildir.Web sunucusu yerel kod ile oluşturulur ve programın bir parçasıdır. Java kullanıyorsanız ve ayrı bir sunucuya ihtiyacınız varsa, değiştirilen kodu dağıtmak için yerel bir sunucuya da ihtiyacınız vardır.

Bu yöntemin en büyük avantajı, yüksek hata ayıklama verimliliğidir. Bu projenin kod değiştirme sıklığı en yüksek olduğundan, bu yöntem hata ayıklama hızını en üst düzeye çıkarabilir. Geliştirme ortamı ile üretim ortamı arasındaki uyumluluktan biraz ödün verilse de telafi edilebilir. Örneğin, yerel projeyi k8s kümesine düzenli aralıklarla (yukarıda belirtilen hata ayıklama araçlarını kullanarak) dağıtabilir ve diğer bağımlı hizmetlerle tüm birleşik hata ayıklamayı gerçekleştirebilirsiniz.Şu anda, işletim ortamı üretim ortamıyla tutarlıdır. Spesifik dağıtım sıklığı kişiye ve projeye bağlıdır ve her gün veya 3 gün veya daha fazla olabilir. Bu, yalnızca normal hata ayıklamanın hızını ve verimliliğini sağlamakla kalmaz, aynı zamanda yerel geliştirme ortamı ve üretim ortamının tutarlılığını da sağlar. Bu model bence daha avantajlı.

Araç özeti

Bu makale, bulut yerel geliştirme ortamını ve aşağıdaki dört kategoriyi içeren gerekli araçları ayrıntılı olarak açıklamaktadır:

• IDE: Temel, k8'leri desteklemeniz gerekiyor.

• k8s: Bu, bulut yerelinin temel taşıdır ve onsuz, bulut yerel olamazdı.

• Miğfer: Geliştirme modu ne olursa olsun, vazgeçilmez bir araçtır.

• Otomatik hata ayıklama aracı: Saf bulut yerel geliştirme modelinde vazgeçilmezdir ve hibrit geliştirme modelinde de gereklidir, ancak saf bulut yerel geliştirme modeli kadar önemli değildir.

Kaynak kod kitaplığı

Tam kaynak kodu için GitHub bağlantısı: k8sdemo (https: // github .com / jfeng45 / k8sdemo)

Terimleri yığmayın, yapıları listelemeyin, otoriteye inanmayın, popüler eğilimleri körü körüne takip etmeyin ve bağımsız düşünmede ısrar etmeyin.

Sorumluluk Reddi: Bu makale, CSDN blog yazarı "Yitian Code Farmer" ın katkısıdır.

Google'ın tekeli, özgür yazılımı öldürmektir

Kafka'nın ilkelerini anlatır mısınız?

@ Programcı, kız arkadaşından başka ne getirmen gerekiyor?

Tencent açık kaynak iyi bir yıl geçiriyor! TencentOS çekirdeği resmi olarak açık kaynaktır

Sızıntıdan kurtulun, Alibaba Cloud Security'nin varsayılan savunması açığa çıktı | Çin'in BT teknolojisi evriminin altını sorun

Apple AirPods yalnızca iPhone için bir aksesuar mıdır?

Yıllarca PHP geliştiricisi olarak, Go dilini kullandıktan sonra ...

Alipay seti Wufu önümüzdeki Pazartesi başlıyor; iPhone 13. yıldönümü; Laravel 6.10.0 çıktı | Geek Manşet

Baidu ERNIE, GLUE yarışmasında Microsoft ve Google'ı yendi

Microsoft, Google, Adobe'yi kazanan Hindistan, teknoloji CEO'ları açısından neden zengin?

"Cennette yapılan kibrit" neye benziyor? Bu karı koca fotoğraf oluşturucu ateşli olacak.

Wechat Mini Program 3 yaşında: günlük aktivite 300 milyonu aşıyor, işlem hacmi 800 milyarı aşıyor