Her şey, geliştirme ekiplerimizden birinin ekip liderinin, bir gün önce konteynere alınmış olan yeni uygulamasını test etmemizi istemesiyle başladı. Ben yayınladım. Yaklaşık 20 dakika sonra uygulamanın güncellenmesi için bir talep geldi çünkü oraya çok gerekli bir şey eklenmişti. Yeniledim. Birkaç saat daha geçtikten sonra... sonrasında ne olacağını tahmin edebilirsiniz...
İtiraf etmeliyim ki oldukça tembelim (bunu daha önce kabul etmedim mi? Hayır?) ve ekip liderlerinin tüm CI/CD'ye sahip olduğumuz Jenkins'e erişimi olduğu gerçeği göz önüne alındığında şöyle düşündüm: Bırakın şu şekilde konuşlandırılsın: istediği kadar! Bir fıkrayı hatırladım: Bir adama balık verirseniz bir gün yiyecektir; Bir kişiye Fed diyorsanız, o tüm hayatı boyunca Beslenecektir. Ve gitti iş yerinde hileler oynaBaşarılı bir şekilde oluşturulmuş herhangi bir sürümün uygulamasını içeren bir konteyneri Kuber'a dağıtabilecek ve ona herhangi bir değeri aktarabilecek ENV (geçmişte bir filolog ve İngilizce öğretmeni olan büyükbabam, bu cümleyi okuduktan sonra şimdi parmağını şakağında çevirir ve bana çok anlamlı bir şekilde bakardı).
Bu notta size nasıl öğrendiğimi anlatacağım:
- Jenkins'teki işleri işin kendisinden veya diğer işlerden dinamik olarak güncelleyin;
- Jenkins aracısının yüklü olduğu bir düğümden bulut konsoluna (Bulut kabuğu) bağlanın;
- İş yükünü Google Kubernetes Engine'e dağıtın.
Aslında biraz samimiyetsiz davranıyorum elbette. Google bulut altyapısının en azından bir kısmına sahip olduğunuz ve dolayısıyla onun kullanıcısı olduğunuz ve elbette bir GCP hesabınız olduğu varsayılmaktadır. Ancak bu notun konusu bu değil.
Bu benim bir sonraki kopya kağıdım. Bu tür notları yalnızca bir durumda yazmak istiyorum: Bir sorunla karşılaştım, başlangıçta onu nasıl çözeceğimi bilmiyordum, çözüm hazır olarak Google'da aratılmadı, bu yüzden parça parça Google'da aradım ve sonunda sorunu çözdüm. Ve gelecekte bunu nasıl yaptığımı unuttuğumda, her şeyi parça parça Google'da aramama ve bir araya getirmeme gerek kalmaması için, kendime böyle kopya kağıtları yazıyorum.
Yasal Uyarı: 1. Not rol için “kendim için” yazılmıştı En iyi uygulama geçerli değildir. Yorumlarda “şöyle yapsaydınız daha iyi olurdu” seçeneklerini okuyunca mutlu oldum.
2. Notanın uygulanan kısmı tuz olarak kabul edilirse, önceki tüm notlarım gibi bu da zayıf bir tuz çözeltisidir.
Jenkins'te iş ayarlarını dinamik olarak güncelleme
Sorunuzu tahmin ediyorum: Dinamik iş güncellemesinin bununla ne ilgisi var? String parametresinin değerini manuel olarak girin ve yola çıkın!
Cevap veriyorum: Gerçekten tembelim, şikayet etmelerinden hoşlanmıyorum: Misha, dağıtım çöküyor, her şey gitti! Bakmaya başlıyorsunuz ve bazı görev başlatma parametrelerinin değerinde bir yazım hatası var. Bu nedenle her şeyi olabildiğince verimli yapmayı tercih ediyorum. Eğer kullanıcının seçim yapabileceği bir değerler listesi vererek doğrudan veri girmesini engellemek mümkünse seçimi düzenliyorum.
Plan şu: Jenkins'te, başlatmadan önce listeden bir sürüm seçebileceğimiz, konteynere aktarılan parametreler için değerleri belirleyebileceğimiz bir iş yaratıyoruz. ENV, ardından kapsayıcıyı toplar ve Container Registry'ye iter. Daha sonra oradan konteyner cuber'de şu şekilde başlatılır: iş yoğunluğu işte belirtilen parametrelerle.
Jenkins'te iş yaratma ve kurma sürecini dikkate almayacağız, bu konu dışı. Görevin hazır olduğunu varsayacağız. Sürümleri içeren güncellenmiş bir listeyi uygulamak için iki şeye ihtiyacımız var: öncelikli olarak geçerli sürüm numaralarına sahip mevcut bir kaynak listesi ve aşağıdaki gibi bir değişken: Seçim parametresi görevde. Örneğimizde değişkene isim verelim BUILD_VERSIONüzerinde ayrıntılı olarak durmayacağız. Ancak kaynak listesine daha yakından bakalım.
O kadar fazla seçenek yok. Hemen aklıma iki şey geldi:
- Jenkins'in kullanıcılarına sunduğu Uzaktan erişim API'sini kullanın;
- Uzak depo klasörünün içeriğini isteyin (bizim durumumuzda bu JFrog Artifactory'dir ve bu önemli değildir).
Jenkins Uzaktan erişim API'si
Yerleşik mükemmel geleneğe göre, uzun açıklamalardan kaçınmayı tercih ederim.
Kendime yalnızca ilk paragrafın bir kısmının ücretsiz çevirisine izin vereceğim :
Jenkins, işlevselliğine uzaktan makine tarafından okunabilen erişim için bir API sağlar. <…> Uzaktan erişim REST benzeri bir tarzda sunulmaktadır. Bu, tüm özelliklere tek bir giriş noktasının olmadığı, bunun yerine " gibi bir URL'nin olduğu anlamına gelir.../api/", Nerede "...", API özelliklerinin uygulandığı nesne anlamına gelir.
Başka bir deyişle, şu anda bahsettiğimiz dağıtım görevi şu adreste mevcutsa: http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, ardından bu göreve ilişkin API düdüklerine şu adresten ulaşabilirsiniz: http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Daha sonra çıktıyı hangi biçimde alacağımızı seçiyoruz. API yalnızca bu durumda filtrelemeye izin verdiği için XML'e odaklanalım.
Tüm işlerin bir listesini almaya çalışalım. Biz yalnızca derleme adıyla ilgileniyoruz (ekran adı) ve sonucu (sonuç):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Anladın mı?
Şimdi yalnızca sonuçla sonuçlanan çalıştırmaları filtreleyelim BAŞARI. Argümanı kullanalım &hariç tutmak ve bir parametre olarak ona eşit olmayan bir değere giden yolu ileteceğiz BAŞARI. Evet evet. Çift olumsuz bir ifadedir. Bizi ilgilendirmeyen her şeyi hariç tutuyoruz:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Başarılı olanlar listesinin ekran görüntüsü
Eh, sırf eğlence olsun diye, filtrenin bizi aldatmadığından emin olalım (filtreler asla yalan söylemez!) ve "başarısız" olanların bir listesini gösterelim:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Başarılı olmayanlar listesinin ekran görüntüsü
Uzak sunucudaki bir klasördeki sürümlerin listesi
Sürümlerin listesini almanın ikinci bir yolu var. Bunu Jenkins API'sine erişmekten daha çok seviyorum. Çünkü uygulama başarılı bir şekilde oluşturulduysa bu, paketlendiği ve uygun klasördeki depoya yerleştirildiği anlamına gelir. Mesela bir depo, uygulamaların çalışan sürümlerinin varsayılan deposudur. Beğenmek. Peki, ona hangi sürümlerin depoda olduğunu soralım. Uzak klasörü kıvıracağız, grep yapacağız ve awk yapacağız. Oneliner'la ilgilenen biri varsa, o zaman spoiler altındadır.
Tek satır komutu
Lütfen iki şeye dikkat edin: Bağlantı ayrıntılarını başlığa aktarıyorum ve klasördeki tüm sürümlere ihtiyacım yok ve yalnızca bir ay içinde oluşturulan sürümleri seçiyorum. Komutu gerçeklerinize ve ihtiyaçlarınıza uyacak şekilde düzenleyin:
curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )Jenkins'te işleri ve iş yapılandırma dosyasını ayarlama
Sürüm listesinin kaynağını bulduk. Şimdi ortaya çıkan listeyi göreve dahil edelim. Benim için bariz çözüm, uygulama oluşturma görevine bir adım eklemekti. Sonuç "başarılı" ise gerçekleştirilecek adım.
Montaj görevi ayarlarını açın ve en aşağıya doğru kaydırın. Düğmelere tıklayın: Derleme adımı ekle -> Koşullu adım (tek). Adım ayarlarında koşulu seçin Mevcut yapım durumu, değeri ayarlayın BAŞARIbaşarılı olması durumunda gerçekleştirilecek eylem Kabuk komutunu çalıştır.
Ve şimdi eğlenceli kısım. Jenkins iş yapılandırmalarını dosyalarda saklar. XML formatında. Yol boyunca http://путь-до-задания/config.xml Buna göre konfigürasyon dosyasını indirebilir, gerektiği gibi düzenleyebilir ve aldığınız yere geri koyabilirsiniz.
Unutmayın, yukarıda sürüm listesi için bir parametre oluşturacağımız konusunda anlaşmıştık. BUILD_VERSION?
Yapılandırma dosyasını indirip içine bir göz atalım. Sadece parametrenin yerinde ve istenen türde olduğundan emin olmak için.
Spoiler altında ekran görüntüsü.
Config.xml parçanız aynı görünmelidir. Seçimler öğesinin içeriğinin henüz eksik olması dışında
Emin misin? İşte bu kadar, build başarılı olursa çalıştırılacak bir script yazalım.
Komut dosyası bir sürüm listesi alacak, yapılandırma dosyasını indirecek, sürüm listesini ihtiyacımız olan yere yazacak ve sonra geri koyacaktır. Evet. Bu doğru. Zaten bir sürüm listesinin bulunduğu yere XML'deki sürümlerin bir listesini yazın (komut dosyasının ilk başlatılmasından sonra gelecekte olacaktır). Dünyada hala düzenli ifadelerin ateşli hayranlarının olduğunu biliyorum. Ben onlara ait değilim. Lütfen yükle yapılandırmanın düzenleneceği makineye. Bana öyle geliyor ki, XML'i sed kullanarak düzenlemekten kaçınmak için bu çok büyük bir bedel değil.
Spoiler altında yukarıdaki sıralamayı gerçekleştiren kodu bütünüyle sunuyorum.
Uzak sunucudaki bir klasördeki sürümlerin listesini yapılandırmaya yazın
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlJenkins'ten sürüm alma seçeneğini tercih ediyorsanız ve siz de benim kadar tembelseniz, spoiler altında aynı kod var ancak Jenkins'in bir listesi var:
Jenkins'ten yapılandırmaya sürümlerin bir listesini yazın
Şunu aklınızda bulundurun: Montaj adım, iki nokta üst üste ile ayrılmış bir sıra numarası ve sürüm numarasından oluşur. Buna göre awk gereksiz kısmı keser. Kendiniz için bu satırı ihtiyaçlarınıza uyacak şekilde değiştirin.
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml
############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlTeorik olarak, yukarıdaki örneklere dayanarak yazılan kodu test ettiyseniz, dağıtım görevinde zaten sürümlerin bulunduğu bir açılır listeye sahip olmalısınız. Spoylerin altındaki ekran görüntüsündeki gibi.
Doğru şekilde doldurulmuş sürüm listesi
Her şey işe yaradıysa betiği kopyalayıp yapıştırın Kabuk komutunu çalıştır ve değişiklikleri kaydedin.
Cloud Shell'e bağlanma
Konteynerlerde toplayıcılarımız var. Ansible'ı uygulama dağıtım aracımız ve konfigürasyon yöneticimiz olarak kullanıyoruz. Buna göre konteyner oluşturmak denildiğinde akla üç seçenek geliyor: Docker'ı Docker'a kurmak, Docker'ı Ansible çalıştıran bir makineye kurmak veya bir bulut konsolunda konteynerler oluşturmak. Bu makalede Jenkins için eklentiler konusunda sessiz kalma konusunda anlaştık. Hatırlamak?
Karar verdim: peki, "kutudan çıkan" konteynerler bulut konsolunda toplanabildiğine göre, o zaman neden uğraşasınız ki? Temiz tut, değil mi? Jenkins konteynerlerini bulut konsolunda toplamak ve ardından onları oradan küp oluşturucuya başlatmak istiyorum. Üstelik Google'ın altyapısında çok zengin kanallar var ve bu da dağıtım hızına olumlu etki yapacak.
Bulut konsoluna bağlanmak için iki şeye ihtiyacınız vardır: bulut ve erişim hakları Google Cloud API'sı aynı bağlantının kurulacağı VM örneği için.
Google bulutundan hiç bağlanmayı planlayanlar için
Google, hizmetlerinde etkileşimli yetkilendirmeyi devre dışı bırakma olanağına izin verir. Bu, *nix çalıştırıyorsa ve bir konsolu varsa, bir kahve makinesinden bile konsola bağlanmanıza olanak tanır.
Bu not çerçevesinde bu konuyu daha detaylı ele almam gerekirse yorumlara yazın. Yeterli oy alırsak bu konu hakkında bir güncelleme yazacağım.
Hakları vermenin en kolay yolu web arayüzünden geçer.
- Daha sonra bulut konsoluna bağlanacağınız VM örneğini durdurun.
- Örnek Ayrıntılarını açın ve tıklayın Değiştirmek.
- Sayfanın en altında örnek erişim kapsamını seçin Tüm Bulut API'lerine tam erişim.
Ekran Görüntüsü
- Değişikliklerinizi kaydedin ve örneği başlatın.
VM'nin yüklenmesi tamamlandıktan sonra SSH aracılığıyla ona bağlanın ve bağlantının hatasız gerçekleştiğinden emin olun. Şu komutu kullanın:
gcloud alpha cloud-shell ssh Başarılı bir bağlantı buna benzer
GKE'ye dağıt
Tamamen IaC'ye (Kod Olarak Altyapı) geçmek için mümkün olan her yolu denediğimizden, docker dosyalarımız Git'te depolanıyor. Bu bir yandan. Kubernetes'te dağıtım, yalnızca bu görev tarafından kullanılan ve kendisi de koda benzeyen bir yaml dosyasıyla tanımlanır. Bu diğer taraftan. Genel olarak plan şu:
- Değişkenlerin değerlerini alıyoruz BUILD_VERSION ve isteğe bağlı olarak aktarılacak değişkenlerin değerleri ENV.
- Docker dosyasını Git'ten indirin.
- Dağıtım için yaml oluşturun.
- Bu dosyaların her ikisini de scp aracılığıyla bulut konsoluna yüklüyoruz.
- Orada bir konteyner oluşturuyoruz ve onu Container kayıt defterine gönderiyoruz
- Yük dağıtım dosyasını cuber'a uyguluyoruz.
Daha spesifik olalım. Bir kez konuşmaya başladık ENV, o zaman iki parametrenin değerini aktarmamız gerektiğini varsayalım: PARAM1 и PARAM2. Dağıtım için görevlerini ekliyoruz, şunu yazın - Dize Parametresi.
Ekran Görüntüsü
Basit bir yönlendirmeyle yaml oluşturacağız kaçırmak dosyalamak. Elbette docker dosyanızda olduğu varsayılmaktadır. PARAM1 и PARAM2yük adı olacak harika uygulamave belirtilen versiyonun uygulanmasıyla birleştirilmiş konteyner Kapsayıcı kayıt defteri yol boyunca gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONNerede $BUILD_VERSION açılır listeden seçildi.
Takım listesi
touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo " name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo " replicas: 1" >> deploy.yaml
echo " selector:" >> deploy.yaml
echo " matchLabels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " template:" >> deploy.yaml
echo " metadata:" >> deploy.yaml
echo " labels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " spec:" >> deploy.yaml
echo " containers:" >> deploy.yaml
echo " - name: awesomeapp" >> deploy.yaml
echo " image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo " env:" >> deploy.yaml
echo " - name: PARAM1" >> deploy.yaml
echo " value: $PARAM1" >> deploy.yaml
echo " - name: PARAM2" >> deploy.yaml
echo " value: $PARAM2" >> deploy.yamlJenkins temsilcisini kullanarak bağlandıktan sonra gcloud alfa bulut kabuğu ssh etkileşimli mod mevcut değil, bu nedenle parametreyi kullanarak bulut konsoluna komutlar gönderiyoruz --emretmek.
Bulut konsolundaki ana klasörü eski docker dosyasından temizliyoruz:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Yeni indirilen docker dosyasını scp kullanarak bulut konsolunun ana klasörüne yerleştirin:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Container'ı topluyor, etiketliyor ve Container kayıt defterine gönderiyoruz:
gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
Aynısını dağıtım dosyasıyla da yapıyoruz. Lütfen aşağıdaki komutların dağıtımın gerçekleştiği kümenin hayali adlarını kullandığını unutmayın (awsm kümesi) ve proje adı (harika proje), kümenin bulunduğu yer.
gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project &&
kubectl apply -f deploy.yaml"Görevi çalıştırıyoruz, konsol çıktısını açıyoruz ve konteynerin başarılı bir şekilde birleştirildiğini görmeyi umuyoruz.
Ekran Görüntüsü
Ve ardından birleştirilmiş konteynerin başarılı bir şekilde konuşlandırılması
Ekran Görüntüsü
Ayarı kasıtlı olarak göz ardı ettim Giriş. Basit bir nedenden dolayı: bir kere kurduktan sonra iş yoğunluğu belirli bir adla, bu adla kaç tane dağıtım gerçekleştirirseniz gerçekleştirin, çalışır durumda kalacaktır. Genel olarak bu tarihin kapsamının biraz ötesinde.
Sonuç yerine
Yukarıdaki adımların tümü muhtemelen gerçekleştirilemezdi, ancak sadece Jenkins için bir eklenti kurdular. Ama bazı nedenlerden dolayı eklentileri sevmiyorum. Daha doğrusu, onlara yalnızca çaresizlikten başvuruyorum.
Ve kendim için yeni bir konu seçmeyi seviyorum. Yukarıdaki metin aynı zamanda başlangıçta anlatılan problemi çözerken elde ettiğim bulguları paylaşmanın bir yoludur. Onun gibi devops'ta hiç de korkunç bir kurt olmayanlarla paylaşın. Bulgularım en azından birisine yardımcı olursa mutlu olacağım.
Kaynak: habr.com