Konteynırlarda sürekli konuşlandırmanın ön keşfi
Yazar | Yitian Coder
Baş Editör | Xu Weilong
Mühür görüntüsü | Görsel Çin'de CSDN indirme
Sürekli entegrasyonu ve sürekli dağıtımı anlamak için önce bileşenlerini ve bileşenler arasındaki ilişkiyi anlamalıyız. Aşağıdaki resim, şimdiye kadar gördüğüm en basit ve en net sürekli dağıtım ve entegrasyon şemasıdır.
Resim kaynağı: sonatype.com
Sürekli dağıtım
Şekilde görüldüğü gibi geliştirme süreci şu şekildedir:
Programcı, kaynak kodu kaynak kontrol kitaplığından indirir, programı yazar ve tamamlandıktan sonra kodu kaynak kitaplığa gönderir.Sürekli Entegrasyon aracı, kaynak kodunu kaynak kitaplığından indirir, kaynak kodu derler ve ardından çalışma zamanı kitaplığına gönderir ( Depo) ve ardından Sürekli Teslimat aracı Kod Deposundan kod indirir, bir yayın sürümü oluşturur ve bunu farklı işletim ortamlarına (DEV, QA, UAT, PROD gibi) yayınlar.
Şekilde, sol kısım, esas olarak geliştirme ve programcılar ile ilgili olan sürekli entegrasyondur; sağ kısım, esas olarak test, çalıştırma ve bakım ile ilgili olan sürekli dağıtımdır. Sürekli teslim (Sürekli Dağıtım), aynı zamanda sürekli dağıtım (Sürekli Dağıtım) olarak da adlandırılır, eğer alt bölümlere ayrılmışlarsa, yine de küçük bir fark vardır, ancak burada, topluca sürekli dağıtım olarak adlandırılan çok fazla ayırt etmiyoruz. Bu makale sürekli dağıtıma odaklanmaktadır.
Sürekli entegrasyon ve dağıtımda aşağıdaki ana oyuncular bulunur:
Kaynak kod kitaplığı: Kaynak kodunu depolamaktan sorumlu olan, yaygın olarak kullanılan Git ve SVN'dir.
Sürekli entegrasyon ve dağıtım araçları: Çalıştırılabilir kitaplıklarda çalıştırılabilir programların otomatik olarak derlenmesinden ve paketlenmesinden ve depolanmasından sorumludur. Daha popüler olanlar Jenkins, GitLab, Travis CI, CircleCI vb.
Depo Yöneticisi: Program bileşenlerini yönetmekten sorumlu olan ve aynı zamanda çalışma zamanı olarak da adlandırılan Depodur. En yaygın kullanılan Nexus'tur. Özel bir kitaplıktır ve rolü program bileşenlerini yönetmektir.
Kütüphane yöneticisinin iki işlevi vardır:
Üçüncü taraf kitaplıklarını yönetin: Uygulamalar genellikle birçok üçüncü taraf kitaplığı kullanır ve farklı teknoloji yığınları farklı kitaplıklar gerektirir ve genellikle üçüncü taraf halk kitaplıklarında depolanır ve bu da yönetilmesi pek uygun değildir. Genellikle şirketler, çeşitli üçüncü taraf yazılımlarını merkezi olarak yönetmek için özel bir yönetim kitaplığı oluşturacaklardır.Örneğin, bir Maven kitaplığı (Java), bir ayna kitaplığı (Docker) veya bir NPM kitaplığı (JavaScript) olarak kullanılabilir. , Firma yazılımlarının standardizasyonunu sağlamak.
Dahili prosedürlerin sunumunu yönetin: Şirketler tarafından çeşitli ortamlarda (DEV, QA, UAT, PROD gibi) yayınlanan tüm programlar, bu program tarafından yönetilir ve birleşik bir sürüm numarası atanır, böylece herhangi bir teslimat belgelenebilir ve program geri dönüşü için uygundur.
Sürekli dağıtım adımları
Her şirketin Sürekli Dağıtım için farklı gereksinimleri vardır ve adımları farklıdır, ancak esas olarak aşağıdaki adımları içerir:
Kaynak kodunu indirin: Kaynak kodunu kaynak kodu havuzundan (github gibi) indirin.
Kodu derleyin: Bu adım, derlenen diller için gereklidir
Ölçek: Programı test edin.
Bir ayna oluşturun: Burada iki adım var, biri bir ayna oluşturmak, diğeri aynayı ayna kitaplığında depolamak.
Dağıtım görüntüsü: Oluşturulan görüntüyü kapsayıcıya dağıtın
Yukarıdaki işlem, genelleştirilmiş bir sürekli dağıtım sürecidir Dar bir şekilde tanımlanmış süreç, kitaplık yöneticisinden çalıştırılabilir programları geri getirmektir Bu, kaynak kodunun indirilmesi ve kodun derlenmesi bağlantısını kaydeder, bunun yerine çalıştırılabilir programları doğrudan kitaplık yöneticisinden indirir. Ancak her şirketin ayrı bir kütüphane yöneticisi olmadığından, burada her şirket için geçerli olan genelleştirilmiş bir sürekli dağıtım süreci benimsenmiştir.
Sürekli dağıtım örneği
Aşağıda, sürekli dağıtımın nasıl tamamlanacağını göstermek için belirli bir örnek kullanıyoruz. Jenkins'i sürekli bir dağıtım aracı olarak kullanıyoruz ve bir Go programını k8s ortamına dağıtmak için kullanıyoruz.
Sürecimiz temelde yukarıda bahsettiğimiz dar süreçtir, ancak Nexus olmadığı için onu biraz değiştirdik ve kaynak programı doğrudan kaynak kitaplıktan indirdik. Adımlar şu şekildedir:
Kaynak kodunu indirin: kaynak kodunu github'dan Jenkins işletim ortamına indirin
Test: Bu adım için gerçek içerik yok
Görüntü oluştur: Bir görüntü oluşturun ve Docker hub'a yükleyin.
Görüntüyü dağıt: oluşturulan görüntüyü k8s'ye dağıt
Bir Jenkins projesi oluşturmadan önce bazı hazırlıklar yapın:
-
Docker Hub hesabı oluşturun
Görüntüyü yükleyebilmek için Docker Hub'da bir hesap ve görüntü deposu oluşturmanız gerekir. Spesifik süreç burada ayrıntılı olarak açıklanmamaktadır, lütfen ilgili bilgilere bakın.
-
Jenkins'te Kimlik Bilgileri Oluşturun
Gelecekte Jenkins komut dosyasında değişkenler tarafından referans alınabilecek Docker hub'ına erişmek için kullanıcı ve parolayı ayarlamanız gerekir, böylece parola programda açık kodda görünmez.
Bir yönetici hesabıyla Jenkins ana sayfasında oturum açtıktan sonra, Manage Jenkins- "Credentials-" System - "Global Credentials -" Add Credentials'ı bulun ve aşağıdaki şekilde gösterildiği gibi Docker Hub kullanıcı adınızı ve şifrenizi girin. "ID", daha sonra komut dosyasında alıntı yapacağınız şeydir.
-
Docker ve k8s önceden yüklenmiş olarak bir Jenkins görüntüsü oluşturun
Jenkins'in varsayılan konteynerinde Docker ve k8'ler yoktur, bu yüzden daha sonra detaylı olarak açıklanacak olan Jenkins imajına dayalı yeni bir imaj oluşturmamız gerekiyor.
Aşağıdaki resim dosyasıdır (Dockerfile-modifiye-jenkins)
Jenkins / jenkins'ten: lts
KULLANICI kökü
ENV DOCKERVERSION = 19.03.4
RUN curl -fsSLO https://download.docker.com/linux/static/stable/x86_64/docker-${DOCKERVERSION}.tgz \
tar xzvf penceresi - $ {DOCKERVERSION} .tgz --şerit 1 \
-C / usr / local / bin docker / docker \
rm docker - $ {DOCKERVERSION} .tgz
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ amd64 / kubectl \
chmod x ./kubectl \
mv ./kubectl / usr / local / bin / kubectl
Yukarıdaki görüntü, Docker ve kubectl'i "jenkins / jenkins: lts" temelinde yükler, böylece bu iki yazılım desteklenir. Docker'ın 19.03.4 sürümü görüntüde kullanılmıştır. Burada kurulu olan sadece "Docker CLI" dir, Docker motoru yoktur. Kullanırken yine de sanal makinenin hacmini konteynere bağlamanız ve sanal makinenin Docker motorunu kullanmanız gerekir. Bu nedenle, kapsayıcıdaki Docker sürümünün sanal makinenin Docker sürümüyle tutarlı olmasını sağlamak en iyisidir.
Docker sürümünü görüntülemek için aşağıdaki komutu kullanın:
vagrant @ ubuntu-xenial: / $ docker sürümü
Ayrıntılar için lütfen Kubernetes üzerinde Jenkins ile bir CI / CD ardışık düzeni yapılandırma bölümüne bakın: https://developer.ibm.com/tutorials/configure-a-cicd-pipeline-with-jenkins-on-kubernetes/
Hazırlıklar tamamlandı ve şimdi Jenkins projesi resmi olarak oluşturuldu:
-
Jenkins komut dosyası:
Projenin oluşturulması Jenkins ana sayfasında yapılır.Adı "jenkins-k8sdemo". En önemli kısmı betik kodudur. Ayrıca Go programı ile aynı kaynak kodu kütüphanesinde saklanır. Dosya adı da "jenkins- k8sdemo ". Projenin script sayfası aşağıdaki şekilde gösterilmektedir.
Jenkins projelerini kurmaya ve oluşturmaya aşina değilseniz, lütfen k8'lere Jenkins yükleme ve SSS bölümüne bakın.
Aşağıdaki jenkins-k8sdemo komut dosyasıdır:
def POD_LABEL = "k8sdemopod - $ {UUID.randomUUID.toString}"
podTemplate (etiket: POD_LABEL, bulut: 'kubernetes', kapsayıcılar :,
ciltler :) {
düğüm (POD_LABEL) {
def kubBackendDirectory = "/ script / kubernetes / arka uç"
stage ('Checkout') {
container ('modifiye-jenkins') {
sh'echo github'dan kaynak al '
git'https: //github.com/jfeng45/k8sdemo '
}
}
stage ('Build image') {
def imageName = "jfeng45 / jenkins-k8sdemo: $ {env.BUILD_NUMBER}"
def dockerDirectory = "$ {kubBackendDirectory} / docker / Dockerfile-k8sdemo-arka uç"
container ('modifiye-jenkins') {
withCredentials () {
sh "" "
docker girişi -u $ {DOCKER_HUB_USER} -p $ {DOCKER_HUB_PASSWORD}
docker build -f $ {WORKSPACE} $ {dockerDirectory} -t $ {imageName}.
docker push $ {imageName}
"" "
}
}
}
stage ('Dağıt') {
container ('modifiye-jenkins') {
sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-deployment.yaml"
sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-service.yaml"
}
}
}
}
Kodu parça parça inceleyelim:
Kapsayıcı görüntüsünü ayarlayın:
podTemplate (etiket: POD_LABEL, bulut: 'kubernetes', kapsayıcılar :,
ciltler :)
Bir önceki adımda oluşturduğumuz "jfeng45 / modifiye-jenkins: 1.0" 'ı kullanarak Jenkins çocuk düğümü Pod'unun kapsayıcı görüntüsünü buraya ayarlayın. Komut dosyasındaki (sahne) tüm adımlar bu resmi kullanır. "Birimler:", birimleri Jenkins kapsayıcısına bağlamak için kullanılır, böylece Jenkins çocuk düğümleri sanal makinenin Docker motorunu kullanabilir.
Jenkins komut dosyası komutları ve bağlama birimlerinin ayarlanması için lütfen jenkinsci / kubernetes-eklentisine bakın
https://github.com/jenkinsci/kubernetes-plugin
-
Bir ayna oluşturun:
Aşağıdaki kod, Go programının Docker imaj dosyasını oluşturur.Burada Docker eklentisini kullanmıyoruz, ancak Docker komutunu doğrudan çağırıyoruz.Faydaları daha sonra tartışılacaktır. Docker kitaplığına erişmek için daha önce kurduğumuz "Docker hub" kimlik bilgilerine başvurur. Komut dosyasında, önce "Docker hub" 'a giriş yapıyoruz, ardından bir yansıtma oluşturmak için önceki adımda GitHub'dan indirilen kaynak kodunu kullanıyoruz ve son olarak yansıtmayı "Docker hub" a yüklüyoruz. onların arasında
"ÇALIŞMA ALANI" Jenkins önceden tanımlanmış bir değişkendir. GitHub'dan indirilen kaynak kodu "{ÇALIŞMA ALANI}" içinde saklanır.
stage ('Build image') {
def imageName = "jfeng45 / jenkins-k8sdemo: $ {env.BUILD_NUMBER}"
def dockerDirectory = "$ {kubBackendDirectory} / docker / Dockerfile-k8sdemo-arka uç"
container ('modifiye-jenkins') {
withCredentials () {
sh "" "
docker girişi -u $ {DOCKER_HUB_USER} -p $ {DOCKER_HUB_PASSWORD}
docker build -f $ {WORKSPACE} $ {dockerDirectory} -t $ {imageName}.
docker push $ {imageName}
"" "
}
}
}
Jenkins komutları hakkında daha fazla bilgi edinmek istiyorsanız lütfen Kubernetes ile Jenkins CI / CD Ardışık Düzeni Kurma konusuna bakın.
https://akomljen.com/set-up-a-jenkins-ci-cd-pipeline-with-kubernetes/
Go programının imaj dosyasını burada yeniden oluşturmadık, ancak daha önce k8s tarafından oluşturulan Go programının imaj dosyasını yeniden kullandık. Go programının imaj dosyası yolu "\ script \ kubernetes \ backend \ docker \ Dockerfile-k8sdemo- arka uç ".
Kodu aşağıdaki gibidir. Bunun faydaları daha sonra tartışılacaktır.
# vagrant @ ubuntu-xenial: ~ / app / k8sdemo / script / kubernetes / arka uç $
# docker build -t k8sdemo-arka uç.
Golang'DAN: inşaatçı olarak en son
# Konteyner içindeki Mevcut Çalışma Dizinini ayarlayın
WORKDIR / uygulama
KOPYA go.mod go.sum ./
RUN go mod indir
KOPYALA ..
WORKDIR / uygulama / cmd
# Go uygulamasını oluşturun
#RUN CGO_ENABLED = 0 GOOS = linux go build -a -installsuffix cgo -o main.exe
ÇALIŞTIR go build -o main.exe
######## Sıfırdan yeni bir aşamaya başlayın #######
ALPİN'DEN: en son
ÇALIŞTIR apk - önbellek yok ca-sertifikaları ekle
WORKDIR / kök /
ÇALIŞTIR mkdir / lib64 ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2
# Önceden oluşturulmuş ikili dosyayı önceki aşamadan kopyalayın
KOPYA --from = oluşturucu /app/cmd/main.exe.
# Yürütülebilir dosyayı çalıştırma komutu
# CMD exec / bin / bash -c "tuzak: TERM INT; sonsuz uyku ve bekle"
CMD
Go görüntü dosyaları hakkında daha fazla bilgi için lütfen Optimize edilmiş Go görüntü dosyaları ve çukurlar oluşturma konusuna bakın.
https://blog.csdn.net/weixin_38748858/article/details/102714799
Dağıtım görüntüsü:
Ardından, Go programını k8s'e dağıtın. Kubectl eklentisi burada kullanılmaz. Bunun yerine, mevcut k8s dağıtım ve hizmet yapılandırma dosyalarını çağırmak için kubectl komutunu kullanın (oluşturulan Go görüntüsü dosyada belirtilecektir). Faydaları daha sonra tartışılacaktır. To.
stage ('Dağıt') {
container ('modifiye-jenkins') {
sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-deployment.yaml"
sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-service.yaml"
}
}
K8'lerin dağıtımı ve hizmet yapılandırma dosyalarının ayrıntıları için, lütfen uygulamaları k8'lere geçirirken neleri değiştirmem gerekiyor?
https://blog.csdn.net/weixin_38748858/article/details/102758381
-
Bildirge neden işe yaramaz?
Pipeline'ı komut dosyalarında yazmanın iki yolu vardır: "Scripted Pipleline" ve "Declarative Pipleline" Burada ilk yöntem kullanılır. "Bildirimli Pipleline" yeni bir yöntem. Kullanmamamın nedeni Bildirime Dayalı modu kullanmaya başlamam ama onu çağırmamamdı. Sonra "Scripted Pipleline" a geçtim ve başarılı oldu. Daha sonra, Bildirimi ayarlama yöntemini, özellikle birimin nasıl monte edileceğini keşfettim, ancak ona baktıktan sonra, "Komut Dosyalı Pipleline" dan çok daha karmaşıktı, bu yüzden tembeldim ve değiştirmedim.
Bildirimli modda takılı birimleri nasıl ayarlayacağınızı öğrenmek istiyorsanız, lütfen Jenkins Pipeline Kubernetes Agent paylaşılan Birimleri konusuna bakın.
https://devops.stackexchange.com/questions/4695/jenkins-pipeline-kubernetes-agent-shared-volumes
-
Otomatik proje:
Jenkins'teki projelerin artık manuel olarak başlatılması gerekiyor.Projeyi otomatik olarak başlatmanız gerekiyorsa, bir webhook oluşturmanız gerekir. Hem GitHub hem de dockerhub web kancalarını destekler ve sayfalarında ayar seçenekleri vardır. "Webhook" bir ters arama URL'sidir. GitHub ve dockerhub, her yeni kod veya yansıtma gönderildiğinde bu URL'yi çağırır. URL, ilgili projenin otomatik olarak başlatılması için Jenkins projesinin adresine ayarlanır.
test sonucu
Artık Jenkins projesi tam olarak yapılandırılmıştır ve sonuçları doğrulamak için projeyi çalıştırmanız gerekir. Projeye başladıktan sonra,
"Konsol Çıkışı" nı kontrol edin, aşağıdakiler çıktının bir parçasıdır (tüm çıktı çok uzun, lütfen eke bakın) ve dağıtımın başarılı olduğunu gösterir.
. . .
kubectl apply -f /home/jenkins/workspace/test1/script/kubernetes/backend/backend-deployment.yaml
deployment.apps / k8sdemo-backend-deployment oluşturuldu
sh kubectl apply -f /home/jenkins/workspace/test1/script/kubernetes/backend/backend-service.yaml
service / k8sdemo-arka uç hizmeti oluşturuldu
}
// kapsayıcı
}
// sahne
}
// düğüm
}
// podTemplate
Boru Hattının Sonu
Tamamlandı: BAŞARI
Çalışan sonuçları görüntüleyin:
Kapsül adını alın:
vagrant @ ubuntu-xenial: / home $ kubectl pod al
İSİM HAZIR DURUM YENİDEN BAŞLATMA YAŞI
envar-demo 1/1 Koşu 1532d
k8sdemo-backend-deployment-6b99dc6b8c-8kxt91/1 Çalıştırma 050s
k8sdemo-database-deployment-578fc88c88-mm6x81/1 Çalıştırma 920d
k8sdemo-jenkins-deployment-675dd574cb-r57sb 1/1 Çalıştırma 02d23h
Bölmede oturum açın ve programı çalıştırın:
vagrant @ ubuntu-xenial: / home $ kubectl exec -ti k8sdemo-arka uç-dağıtım-6b99dc6b8c-8kxt9 - / bin / sh
~ # ./main.exe
DEBU veritabanına bağlan
DEBU dataSourceName: dbuser: dbuser @ tcp (k8sdemo-veritabanı-hizmeti: 3306) / service_config? Charset = utf8
DEBU FindAll
DEBU oluşturuldu = 2019-10-21
DEBU kullanıcıyı bul: {1 Tony IT 2019-10-21}
DEBU kullanıcı listesini bul:
DEBU kullanıcı listesi:
Sonuç doğrudur.
Jenkins ilkesi
Örnek kısım bitti, aşağıda en iyi uygulamaları tartışalım. Bundan önce, önce Jenkins ilkesini bulmalıyız.
-
Yürütülebilir komut
Her zaman bir sorum var, hangi komutların kabuk aracılığıyla Jenkins tarafından çalıştırılabileceği? Jenkins, Docker ve k8'lerden farklıdır. Bunları öğrendiğiniz sürece ikincisi kendi komut setine sahiptir. Jenkins, diğer sistemlerle entegre olarak çalışır, bu nedenle çalıştırılabilir komutları diğer sistemlerle ilişkilidir, bu da hangi komutların çalıştırılabilir hangilerinin çalıştırılamayacağını bilmenizi zorlaştırır. Cevabı almak için ilkesini anlamanız gerekir. Jenkins komut dosyasını çalıştırdığında, ana düğüm otomatik olarak bir çocuk düğüm (Docker konteyneri) oluşturur ve tüm Jenkins komutları bu konteynerde çalıştırılır. Dolayısıyla çalıştırılabilecek komutlar konteyner ile yakından ilgilidir. Genel olarak konuşursak, Linux komutlarını kabuk üzerinden çalıştırabilirsiniz. Sonra şu soru geliyor:
1. Bash'i neden kullanamıyorum?
Çünkü kullandığınız alt düğümün kapsayıcısı, Bash'e sahip olmayan Alpine gibi modern bir Linux sürümünü kullanabilir.
2. Neden Docker komutlarını veya Kubectl'i çalıştıramıyorum?
Varsayılan kapsayıcısı jenkinsci / jnlp-slave olduğundan ve önceden yüklenmiş Docker veya kubectl'e sahip değildir. Varsayılan kapsayıcıyı kullanmak yerine, kendi kabınızı belirleyebilir ve yukarıdaki yazılımı içine önceden yükleyebilir, ardından bu komutları çalıştırabilirsiniz.
-
Dosyalar nasıl paylaşılır
Bir Jenkins projesi tamamlamak için genellikle birkaç adıma (aşamaya) bölünür Örneğin, indirdiğiniz kaynak kodun birkaç adım arasında paylaşılması gerekir. Nasıl paylaşılır? Jenkins, kaynak kod havuzundan ve diğer yerlerden indirilen tüm dosyaları depolayan her proje için bir ÇALIŞMA ALANI (disk alanı) ayırır.Farklı aşamalar dosyaları ÇALIŞMA ALANI aracılığıyla paylaşabilir.
ÇALIŞMA ALANI ile ilgili ayrıntılar için, lütfen Jenkins Projesi Yapıları ve Çalışma Alanı'na bakın.
https://stackoverflow.com/questions/39397329/jenkins-project-artifacts-and-workspace
-
En İyi Uygulamalar
En iyi uygulamaları özetlemek için, sürekli konuşlandırmanın tüm geliştirme sürecindeki rolünü ve konumunu anlamak gerekir ve temelde çeşitli bağlantıları birbirine bağlamada rol oynar. Programın dağıtımı k8s ve Docker tarafından tamamlanır, bu nedenle program dağıtımı için betikler de k8s'de bulunur ve k8s tarafından korunur. Jenkins'te benzer bir betik seti tutmak istemiyoruz, bu yüzden en iyi yol Jenkins betiklerini minimuma sıkıştırmak ve olabildiğince çok k8s betiklerini doğrudan çağırmaktır.
Ek olarak, eğer kod yazabiliyorsanız, sayfada yapılandırmayın.Sadece kod tekrar tekrar çalıştırılabilir ve kararlı sonuçlar elde edilebilir.Sayfa konfigürasyonu nakledilemez ve her konfigürasyonun aynı sonuçları üreteceğinin garantisi yoktur.
-
Eklenti kullanımını en aza indirin
Jenkins'in birçok eklentisi vardır ve temelde başarmak istediğiniz şey için karşılık gelen eklentiler vardır. Örneğin, Docker işlevini kullanmanız gerekiyorsa, bir "Docker Pipeline" eklentisi ve k8s işlevini kullanmak istiyorsanız, bir "kubectl" eklentisi vardır. Ama pek çok sorun getirecek.
İlk olarak, her eklentinin kendi ayar yöntemi vardır (genellikle Jenkins eklenti sayfasında ayarlanır), ancak bu ayar diğer sürekli dağıtım araçlarıyla uyumlu değildir. Gelecekte diğer sürekli dağıtım araçlarına geçmek isterseniz, bu ayarların atılması gerekir.
İkincisi, her eklentinin kendi komut formatı vardır, bu nedenle yeni bir komut seti öğrenmeniz gerekir.
Üçüncüsü, bu eklentiler genellikle yapabileceklerinizi sınırlandıran işlevlerin yalnızca bir kısmını destekler.
Örneğin, bir Docker imaj dosyası oluşturmanız gerekiyor, komut aşağıdaki gibidir, "jfeng45 / jenkins-k8sdemo" adlı bir imaj oluşturacaktır, imajın varsayılan dosyası projenin kök dizinindeki Dockerfile'dır.
app = docker.build ("jfeng45 / jenkins-k8sdemo")
Ancak Docker imaj dosyası oluşturma komutunun birçok parametre seçeneği vardır.Örneğin, imaj dosya adınız Dockerfile değil ve dizin proje kök dizininde değil, nasıl yazmalısınız? Bu, önceki sürümde desteklenmiyor, ancak sonraki sürümler bunu destekliyor, ancak sonuçta pek kullanışlı değil ve yeni komutları öğrenmeniz gerekiyor. En iyi yol, Docker komutunu doğrudan kullanmaktır, bu da yukarıda bahsedilen üç sorunu mükemmel şekilde çözer. Cevap, daha önce bahsedilen Jenkins prensibinde yatmaktadır.Aslında çoğu eklentiye gerek yoktur.Sadece bir Jenkins çocuk düğüm kabı oluşturmanız ve bunu başarılı bir şekilde çözmek için ilgili yazılımı yüklemeniz gerekir.
Aşağıda, eklentiyi kullanan ve kullanılmayan betikler arasında bir karşılaştırma yapılmıştır.Kullanılmayanlar daha uzun görünmektedir.O zaman eklentileri kullanan betikler Jenkins'teki kimlik bilgisi ayarlarıyla daha iyi entegre olduğu için kullanılmayan betikler yoktur. Ancak bu küçük eksikliğin yanı sıra, başka yönlerden kullanılmayan betikler, eklenti kullananlardan çok daha üstündür.
Eklenti komut dosyası kullanın (eklenti komutunu kullanarak):
stage ('Docker görüntüleri oluştur') {
kapsayıcı ('docker') {
app = docker.build ("jfeng45 / codedemo", "-f $ {WORKSPACE} / script / kubernetes / arka uç / docker / Dockerfile-k8sdemo-test.")
docker.withRegistry ('', 'dockerhub') {
// Görüntüyü itin ve sürüm oluşturma amaçları için derleme numaramızla etiketleyin.
app.push ("$ {env.BUILD_NUMBER}")
}
}
}
Eklenti kullanmayan komut dosyaları (doğrudan Docker komutlarını kullanın):
stage ('Bir görüntü oluşturucu görüntüsü oluştur') {
def imageName = "jfeng45 / codedemo: $ {env.BUILD_NUMBER}"
def dockerDirectory = "$ {kubBackendDirectory} / docker / Dockerfile-k8sdemo-arka uç"
container ('modifiye-jenkins') {
withCredentials () {
sh "" "
docker girişi -u $ {DOCKER_HUB_USER} -p $ {DOCKER_HUB_PASSWORD}
docker build -f $ {WORKSPACE} $ {dockerDirectory} -t $ {imageName}.
docker push $ {imageName}
"" "
}
}
}
-
Mümkün olduğunca k8s ve Dcoker kullanın
Örneğin, bir uygulama imajı oluşturmak istiyorsak, bir Docker dosyası yazıp bu Docker dosyasını bir Jenkins betiğinde çağırarak onu oluşturabiliriz veya betikte bir görüntü oluşturmak için bir Jenkins betiği yazabiliriz. Daha iyi yöntem eski yöntemdir. Docker ve k8'lerin ikisi de fiili standartlar olduğundan, nakli çok uygundur.
-
Jenkins betiğinde ne kadar az kod varsa o kadar iyidir
Önceki iki ilkeye katılıyorsanız, bu mantıklıdır ve nedeni yukarıdakiyle aynıdır.
-
yaygın sorun:
1. Değişkenler çift tırnak içine alınmalıdır
Jenkins betikleri tek tırnak veya çift tırnak kullanabilir, ancak bir değişkenden tırnak içinde alıntı yaparsanız çift tırnak kullanın.
Doğru komut:
sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-deployment.yaml"
Yanlış komut:
sh'kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-deployment.yaml '2. docker bulunamadı
Jenkins kapsayıcısında Docker yoksa, ancak Docker komutunu yeniden çağırırsanız, "Konsol Çıktı" nda aşağıdaki hata görünecektir:
docker inspect -f. k8sdemo-arka uç: en yeni
/var/jenkins_home/workspace/k8sdec@2@tmp/durable-01e26997/script.sh: 1: /var/jenkins_home/workspace/k8sdec@2@tmp/durable-01e26997/script.sh: docker: bulunamadı
3. Jenkins düştü
Jenkins'te hata ayıklarken yeni bir imaj dosyası oluşturdum ve bunu "Docker hub" a yükledim ve Jenkins'in çalışmadığını gördüm. Bölmeyi kontrol ettim, bir sorun buldu, k8s Jenkins'in görüntü dosyasını bulamadı (görüntü dosyası diskten kayboldu). Jenkins dağıtım dosyası "imagePullPolicy: Never" olarak ayarlandığından, görüntü gittiğinde otomatik olarak yeniden indirilmeyecektir. Daha sonra sebebini buldum.Vagrant'ın varsayılan disk boyutu 10G.Yeterli alan yoksa, yer açmak için diğer imaj dosyalarını otomatik olarak diskten silecek.Sonuç olarak, Jenkins imaj dosyası silinecek.Çözüm, Vagrant diskini genişletmek. boyut.
Aşağıdaki, disk alanını 16G olarak değiştiren değiştirilmiş Vagrantfile'dır.
Vagrant.configure (2) do | config |
. . .
config.vm.box = "ubuntu / xenial64"
config.disksize.size = '16GB'
. . .
son
Ayrıntılar için bkz. Bir Vagrant VM'de disk boyutunu nasıl artırabilirim?
https://askubuntu.com/questions/317338/how-can-i-increase-disk-size-on-a-vagrant-vm
Kaynak kodu
Tam kaynak kodunun github bağlantısı: https://github.com/jfeng45/k8sdemo
Aşağıda, projenin bu makale ile ilgili bölümleri bulunmaktadır:
ek:
Aşağıda, Jenkins projesi çalıştırıldıktan sonra tam "Konsol Çıkışı" verilmiştir:
Dayanıklılık düzeyinde çalışıyor: MAX_SURVIVABILITY
Ardışık Düzen Başlangıcı
podTemplate
{
düğüm
Hala görevi planlamayı bekliyorum
"K8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3" çevrimdışı
Ajan k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3, Kubernetes Kapsül Şablonu şablonundan sağlanmıştır
Ajan spesifikasyonu (k8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa):
* jfeng45 / değiştirilmiş jenkins: 1.0
K8sdemopod-030ed100-cb28-4770-b6de-c491970e5baa-twb8s-k9pn3 in / home / jenkins / workspace / jenkins-k8sdemo üzerinde çalışıyor
{
sahne
{(Ödeme)
konteyner
{
sh
echo github'dan kaynak al
github'dan kaynak al
git
Kimlik bilgisi belirtilmedi
Uzak Git deposunu klonlama
Klonlama havuzu https://github.com/jfeng45/k8sdemo
> git init / home / jenkins / çalışma alanı / jenkins-k8sdemo # zaman aşımı = 10
Https://github.com/jfeng45/k8sdemo'dan yukarı akış değişiklikleri getiriliyor
> git --version # timeout = 10
> git fetch --tags --force --progress - https://github.com/jfeng45/k8sdemo refs / Heads / *: refs / remotes / origin / *
> git config remote.origin.url https://github.com/jfeng45/k8sdemo # timeout = 10
> git config --add remote.origin.fetch refs / Heads / *: refs / remotes / origin / * # timeout = 10
> git config remote.origin.url https://github.com/jfeng45/k8sdemo # timeout = 10
Https://github.com/jfeng45/k8sdemo'dan yukarı akış değişiklikleri getiriliyor
> git fetch --tags --force --progress - https://github.com/jfeng45/k8sdemo refs / Heads / *: refs / remotes / origin / *
Revizyon 90c57dcd8ff362d01631a54125129090b503364b (refs / remotes / origin / master) kontrol ediliyor
> git rev-ayrıştırma refs / remotes / origin / master ^ {commit} # timeout = 10
> git rev-ayrıştırma refs / remotes / origin / origin / master ^ {commit} # timeout = 10
> git config core.sparsecheckout # timeout = 10
> git ödeme -f 90c57dcd8ff362d01631a54125129090b503364b
> git branch -a -v --no-abbrev # zaman aşımı = 10
> git ödeme -b ana 90c57dcd8ff362d01631a54125129090b503364b
Teslim mesajı: "jenkins sürekli dağıtım dosyaları eklendi"
}
> git rev-list --no-walk 90c57dcd8ff362d01631a54125129090b503364b # timeout = 10
// kapsayıcı
}
// sahne
sahne
{(Görüntü oluştur)
konteyner
{
withCredentials
$ DOCKER_HUB_USER veya $ DOCKER_HUB_PASSWORD için desteklenen kalıp eşleşmeleri maskeleme
{
sh
docker girişi -u **** -p ****
UYARI! CLI aracılığıyla --password kullanımı güvenli değildir. --Password-stdin kullanın.
UYARI! Parolanız /home/jenkins/.docker/config.json içinde şifrelenmemiş olarak saklanacaktır.
Bu uyarıyı kaldırmak için bir kimlik bilgisi yardımcısı yapılandırın. Bkz.
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Giriş Başarılı
docker build -f / home / jenkins / workspace / jenkins-k8sdemo / script / kubernetes / backend / docker / Dockerfile-k8sdemo-backend -t **** / jenkins-k8sdemo: 7.
Docker daemon 218.6kB'ye derleme bağlamı gönderme
Adım 1/13: golang'DAN: inşaatçı olarak en son
--- > dc7582e06f8e
Adım 2/13: WORKDIR / uygulama
--- > C5770704333e'de çalışıyor
Ara kabın çıkarılması C5770704333e
--- > 73445078c82d
Adım 3/13: KOPYALA go.mod go.sum ./
--- > 6762344c7bc8
Adım 4/13: RUN go mod download
--- > 56a1f253c3f5'te çalışıyor
