Bazı küçük ekiplerin otomatikleştirilmiş işletim ve bakımdaki pratik deneyimi
Sektördeki devlerin otomatikleştirilmiş işletme ve bakım mimarisi, aşağıdaki şekilde gösterildiği gibi ulaşılamaz olan çeşitli soğuk işlevlere sahiptir. Artık herkes son bakışı biliyor ama asıl soru, ekibinizin mevcut durumuna göre bu amaca nasıl adım adım ilerleyeceğinizdir.
Yazarın ekibi, üç buçuk geliştirme, düzinelerce bulut makinesini korumak için bir düzineden fazla uygulamayı dağıttı, bu uygulamaların% 90'ı eski sistemlerdir. Uygulama sisteminin derlenmesi ve paketlenmesi temelde programcının kendi bilgisayarındadır. Şube yönetimi aynı zamanda dev şubenin gelişimidir.Test geçildikten sonra ana dalda birleştirilir. Üretim ortamının uygulama yapılandırması, yalnızca belirli bir makinede oturum açtığınızda bilinir, yapılandırma merkezi ve yapılandırma sürümlemesinden bahsetmeye bile gerek yok.
Bu arada, makine düzeyinde temel bir izleme yok.
Her zamanki işim% 50 iş geliştirme,% 50 işletme ve bakımdır. Bu kadar çok sorunla karşılaşınca, düşük maliyetle otomatik çalıştırma ve bakımı nasıl gerçekleştireceğimi merak ettim. Bu makale, bu alandaki deneyimimin ve uygulamamın bir özetidir. Okuyuculara yardımcı olacağını umuyoruz.
Konuşma, önce izleme ve uyarıya git
İş geliştirme gecikse bile, izleme ve uyarı en baştan yapılması gerektiğini düşündüğüm şeyler. Sadece mevcut durumu biliyorsanız bir sonraki adımı atabilirsiniz.
Piyasada birçok izleme sistemi vardır: Zabbix, Open-Falcon, Prometheus. Sonunda yazar Prometheus'u seçti. Çünkü:
Çekme modu
Yapılandırmada sürüm oluşturma için elverişli olan yapılandırmak için metin kullanmak uygundur
Çok fazla eklenti var, temelde izlemek istediğiniz her şey hazır olacak
Temelde yukarıdaki üçü tekrar öğrenmem gerekiyor. Neden bir Google SRE kitabında önerilen birini öğrenmiyorum?
Daha önce tanıttığımız gibi, daha az insan ve daha fazla makine var, bu nedenle Prometheus'u kurma süreci de otomatikleştirilmeli ve versiyonlanmalıdır. Yazar Ansible + Git uygulamasını kullanıyor. Son görünüm aşağıdaki gibidir:
Burada kısa bir giriş gerekiyor:
Prometheus Sunucusu, veri toplama ve depolamanın izlenmesinden sorumludur
Prometheus Uyarı yöneticisi, uyarı kurallarına göre uyarı vermekten sorumludur ve birçok uyarı kanalını entegre edebilir
Düğüm dışa aktarıcının rolü, makineden metrikleri okumak ve ardından bir http hizmetini açığa çıkarmaktır Prometheus bu hizmetten izleme ölçütlerini toplar. Tabii ki, Prometheus'un resmi olarak çeşitli ihracatçıları da var.
Ansible'ı bir dağıtım aracı olarak kullanmanın faydalarından biri, çok fazla hazır rolün olmasıdır.Prometheus'u kurarken hazır olan prometheus-ansble'ı kullandım.
İzleme verilerini elde ettikten sonra verileri görselleştirebiliriz. Grafana ve Prometheus çok iyi entegre olur, bu nedenle Grafana'yı tekrar devreye aldık:
Nodex-exporter tarafından Grafana'da toplanan verilerin etki diyagramı kabaca aşağıdaki gibidir:
Ancak CPU yükünün aşırı olup olmadığını görmek için günün 24 saati ekrana bakmamız imkansız değil mi? Şu anda alarm verilmek üzere Promehtues varsayılan olarak N birden fazla alarm kanalını entegre eder. Maalesef entegre DingTalk yok. Ama önemli değil Bazı tür öğrenciler DingTalk'un Prometheus uyarıları ile entegre ettiği bileşeni açık kaynaklı hale getirdiler: prometheus-webhook-dingtalk. Sonra alarmı aldık:
Yukarıdaki çalışmayı tamamladıktan sonra temel izleme rafımız tamamlandı. Redis izleme ve JVM izleme gibi üst düzey izlememiz için hazırdır.
Konfigürasyon versiyonlama işlemi oyuncak bebekle başlamalıdır
İzleme sistemini kurma sürecinde, konfigürasyonu çıkardık ve yönetim için ayrı bir kod deposuna yerleştirdik. Gelecekteki tüm dağıtımlar için yapılandırma ve dağıtım mantığını ayıracağız.
Ansible'ın konfigürasyon yönetimi için nasıl kullanılacağıyla ilgili olarak şu makaleye bakabilirsiniz: Ansible ile Çok Aşamalı Ortamları Yönetme. Ortam değişkenlerini düzenlemek için bu yöntemi kullanıyoruz.
environment / # Ortama özel dizinlerimiz için ana dizin
dev / # Dev ortamına özgü tüm dosyaları içerir
group_vars / # dev'e özgü group_vars dosyaları
hepsi
db
ağ
hosts # Yalnızca geliştirme ortamındaki ana bilgisayarları içerir
prod / # Üretim ortamına özgü tüm dosyaları içerir
group_vars / # prod'a özgü group_vars dosyaları
hepsi
db
ağ
hosts # Yalnızca üretim ortamındaki ana bilgisayarları içerir
stage / # Sahne ortamına özgü tüm dosyaları içerir
group_vars / # aşamaya özgü group_vars dosyaları
hepsi
db
ağ
hosts # Yalnızca sahne ortamındaki ana bilgisayarları içerir
Bu aşamada, tüm yapılandırmalarımız metin olarak saklanır.Gelecekte, yapılandırma merkezi olarak Consul'u kullanmaya geçeceğiz.Ayrıca çok kullanışlıdır, çünkü Ansible 2.0 ve üzeri yerel olarak entegre Consule: consul_module.
İpuçları: Ansible'ın yapılandırma değişkenleri hiyerarşiktir ve bu, yapılandırma yönetimimiz için büyük esneklik sağlar.
Jenkinsization: Ambalajı Jenkins'e teslim edin
Tüm projelerin ambalajlarını Jenkins'e teslim edeceğiz. Elbette gerçekte ilk olarak paketleme için Jenkins üzerine bazı projeler koyarız ve aşamalı olarak projeleri Jenkins'e koyarız.
Öncelikle Jenkins'e ihtiyacımız var. Ayrıca Jenkins'i oluşturmak için hazır Ansible betikleri de vardır: ansible-role-jenkins. İnternette gördüğüm makalelerin çoğunun size Jenkins'in eklentileri manuel olarak yüklemesi gerektiğini söylediğini ve kullandığımız ansible-role-jenkins'in eklentilerin otomatik kurulumunu gerçekleştirdiğini unutmayın. Yalnızca bir yapılandırma değişkeni eklemeniz gerekir jenkins_plugins. Resmi Örnekler aşağıdaki gibidir:
---
-hosts: tümü
vars:
jenkins_plugins:
-Mavi Okyanus
-ghprb
-yeşil toplar
-iş akışı toplayıcı
jenkins_plugin_timeout: 120
ön_görevler:
-include_görevler: Java-8.yml
roller:
-geerlingguy.java
-ansible-role-jenkins
Jenkins'i kurduktan sonra, Gitlab'ı entegre etme zamanı geldi. Zaten Gitlab'ımız var, bu yüzden onu yeniden inşa etmeye gerek yok. Nasıl entegre edileceği ayrıntılı değil, internette zaten birçok makale var.
Sonunda, Jenkins şöyle inşa edildi:
Jenkins master ve Jenkins ajanı arasındaki bağlantıyla ilgili olarak, farklı ağ ortamları nedeniyle, İnternette de birçok yol vardır, böylece uygun yolu seçebilirsiniz.
Tamam, şimdi Jenkins'e iş kodumuzu nasıl derleyeceğini ve paketleyeceğini söylememiz gerekiyor. İki yol var:
Arayüzdeki ayarlar
Jenkinsfile'ı kullanın: Dockerfile'a benzer bir metin dosyası, özel giriş: Jenkinsfile kullanma
Yazar ikinci türü seçmekte tereddüt etmedi, çünkü biri sürüm oluşturmaya elverişli, diğeri esnek.
Jenkinsfile şuna benzer:
boru hattı {
ajan herhangi biri
aşamalar {
stage ('Build') {
adımlar {
sh './ gradlew clean build'
archiveArtifacts artifacts: '** / target / *. jar', parmak izi: true
}
}
}
}
Peki Jenkinsfile nerede? Bunu iş koduyla bir araya getirin, buna benzer şekilde, her proje kendi Jenkins dosyasını yönetir:
Bu noktada, Jenkins üzerinde bir pipleline işi oluşturabiliriz:
Şube yönetimi ile ilgili olarak, az sayıda çalışanımız olduğundan, tüm projelerin ana şubede geliştirilmesi ve yayınlanması tavsiye edilmektedir.
Jenkins, Ansible'ı uygulamamıza yardım etsin
Hepimiz Ansible'ı programcının bilgisayarında çalıştırmadan önce, şimdi bu işi Jenkins'e devredeceğiz. Özel işlem:
Ansible eklentisini Jenkins'e yükleyin
Jenkinsfile'da çalıştır
withCredentials () {
ansiblePlaybook vaultCredentialsId: 'vault_password', envanter: "environment / prod", playbook: "playbook.yaml",
extraVars:
}
İşte açıklanmalıdır:
ansiblePlaybook, manuel yürütmeye benzer şekilde Jenkins ansible eklentisi tarafından sağlanan bir ardışık düzen sözdizimidir: ansible-playbook.
withCredentials, Ansible'ı çalıştırırken gerekli olan ssh anahtarı ve Ansible Vault parolası gibi bazı hassas bilgilere başvurmak için kullanılan Credentials Binding eklentisinin sözdizimidir.
Bazı hassas yapılandırma değişkenleri Ansible Vault teknolojisi kullanılarak şifrelenir.
Ansible komut dosyaları nereye yerleştirilmelidir?
Her projenin kendi otomatik yapımından sorumlu olduğunu zaten biliyoruz, bu nedenle Jenkinfile kendi projelerine yerleştirilir. Projenin konuşlandırılması ne olacak? Aynı nedenle, her projenin bundan sorumlu olması gerektiğini düşünüyoruz, bu nedenle dağıtılacak projelerimizin her birinde Ansible betiklerini saklamak için yanıtlanabilir bir dizin olacak. Bunun gibi bir şey:
Ama nasıl kullanılır? Ansible dizinini paketleme aşamasında sıkıştıracağız. Gerçekte konuşlandırıldığında, içindeki başucu kitabını açın ve çalıştırın.
Tüm projeler için hızlıca Ansible betikleri ve Jenkinsfiles oluşturun
Yukarıda, biz Jenkins ve Ansible bir projeyiz, ancak yine de aynısını yapması gereken birçok projemiz var. Bunun manuel bir çalışma olduğunu ve gelecekte sık sık böyle şeyler yapacağımızı göz önünde bulundurarak, otomatik olarak Jenkinsfile ve Ansible betiklerini oluşturmak için cookiecutter teknolojisini kullanmaya ve şöyle bir proje oluşturmaya karar verdim:
özet
Özetle, küçük ekibimizin otomatik operasyon ve bakım sıralaması kabaca aşağıdaki gibidir:
Temel izleme
Gitlab'a git
Jenkins'e gidin ve Gitlab'ı entegre edin
Otomatik derleme ve paketlemeyi gerçekleştirmek için Jenkins'i kullanın
Ansible'ı Jenkins ile çalıştırın
Yukarıdakiler sadece bir raf Bu raf a dayanarak, bu büyük fabrikaların yüksek mimarisine dönüşebiliriz. gibi:
CMDB yapımı: Envantere dayalı olarak tüm makinelerin mevcut durumunu otomatik olarak oluşturmak için yanıtlanabilir cmdb kullanıyoruz
Sürüm yönetimi: Sürümün her aşaması Jenkins üzerinde özelleştirilebilir. Mavi-yeşil sürüm gibi serbest bırakma yöntemleri Ansible komut dosyalarını ve Envanter'i değiştirerek uygulanabilir.
Otomatik genişleme ve daralma: Prometheus alarm kurallarını yapılandırarak ve ilgili web kancasını arayarak elde edilebilir.
ChatOps: ChatOps iş başında
