Kod deposunda DevOps ile ilgili kod ve yapılandırmalar nasıl yapılandırılır?


10

Bir şirket olarak büyüyoruz, ürünlerimiz genişliyor ve DevOps ile ilgili faaliyetlerimiz ve çabalarımız da büyüyor - dağıtım boru hatları ve diğer eklentileri kullanarak Bambu'dan daha esnek ve yapılandırılabilir bir Jenkins'e geçtik; Ansible'a geçti ve burada ve orada Docker'ı kullanmaya başladı.

Tüm bunlar bir miktar kodlama veya yapılandırma gerektirir - Ansible komut dosyaları ve yapılandırmaları, Jenkins groovy komut dosyaları, Dockerfiles ve YAML yapılandırmaları.

Şimdilik, biz üst düzey dizinleri ile ayrı bir "op" depo oluşturduk jenkins, ansible, dockerve other(korkunç adıdır, ancak şimdilik tüm "öteki" DevOps otomasyon şeyler vardır ki).

Yaklaşımımız doğru gelmiyor ve ölçeklenmiyor olabilir, ancak DevOps ile ilgili kodu bir kod havuzunda veya depolarında tutmak için en iyi uygulamalar ve öneriler nelerdir?


6
Ben "her bölüm bir uygulama, uygulama başına bir repo" yöntemi ile gitmek, şef yemek kitabı başına 1 repo anlamına gelir.
Tensibai

@Tensibai doğru, tek bir "ops" deposunun çabucak pratik olmayacağından korktum. Teşekkürler.
alecxe

1
Bu şef yemek kitabı yönetiminin eski formu, tüm yemek kitabı ile 1 repo ve bu nedenle çoğu durumda bir tabanca kanıtlanmış, ama aynı zamanda uygun olacağını söylemek daha az rahat değilim, Jenkins boru hatları (v2) ve docker dosyaları
IMO'yu işledikleri

@Tensibai anladı! Diğerleri çoğunlukla bash ve python yardımcı programlarından veya birden çok dahili araç için periyodik olarak çalıştırılan komut dosyalarından oluşur ... gerçekten hiçbir yere sığmazlar ve "diğer" den daha iyi bir yer düşünemedik .. İçeriği gönderebilir miyim Dizinleri de soruna dahil eder. Teşekkürler.
alecxe

1
Onları işin yakınlığı, uygulama X üzerinde birlikte çalışan komut dosyaları ile birden fazla repoda bölebilirim, iki uygulamada kullanılan bir komut dosyanız olabilir, ancak uygulama Bir komut dosyasının, konuştuğu uygulamayı ele alması gereken bir değişiklik varsa , iki ayrı sürümün olması daha iyidir, bu yüzden ATEOTD İlgili oldukları uygulama ile veya görev başına belirli bir havuzda birden fazla uygulamayı yayıyorlarsa depolardım, böylece her zaman konuşlandırılmış uygulamalara uygun bir sürümünüz olur ve İlişkisiz bir komut dosyasını aynı anda etiketlemenize gerek yoktur.
Tensibai

Yanıtlar:


4

Açıkladığınız kod ve konfigürasyonun mevcut organizasyonu, ilgili teknik çözümler tarafından yapılandırılmıştır. Bu, bakım faaliyetlerimize çok fazla yük ekleyecek ve yolumuza da çok sayıda tuzak katacak kötü bir tasarım. Bunun yerine, bu organizasyon dağıttığımız eserler etrafında yapılandırılmalıdır .

Bunun nedeni, artefaktları ( örn. Bir docker görüntüsü veya bir yazılım paketi) aşağıdaki fiillerin nesneleri olarak değerlendirmek istememizdir :

  • inşa etmek
  • Ölçek
  • dağıtmak

gerçekleştirmek istediğimiz en az otomatik görevleri dikkate almak. Test fiilinin nasıl uygulandığı hakkında bir şey değiştirmek istersek, uygun depoda bu artefakta karşılık gelen klasörü ziyaret etmek ve daha sonra güncellenmesi gereken jenkinlere özgü otomasyon öğelerini keşfetmek kolaydır. Bunun yerine, otomasyon tarifleri teknik çözümler etrafında yapılandırılmışsa, o zaman jenkinlerin test prosedürlerine dahil olduğunu ve artefakt ile ilgili otomasyon öğelerini bulduklarını bulmalıyız. Karmaşık durumlarda, teknik çözümlerin etrafındaki organizasyon güncellemeleri çok zorlaştırır, çünkü bazı hizmetlerde yer alan tüm teknik çözümleri önceden güncellemek zorundayız.

Örneğin, bir web sitesinin kodunu ve "a" mikro hizmetini içeren bir havuz, işlemlere ayrılmış aşağıdaki alt dizinlere sahip olabilir:

./ops/website
./ops/micro-service-a

Herbiri üçer komut adı verilen build, testve deploy. Otomasyon ürünlerinin organizasyonu bir şekilde netleştiğine göre, dikkatimizi konfigürasyona çevirelim.

Konfigürasyon organizasyonu ile ilgili ana şartlar ve gereksinimler, deployservis benzeri bir nesneye uygulandığında fiil tarafından belirlenir . deployFiili aşağıdaki parametrelere sahip olması gerekir:

  • konuşlandırılacak eserin sürümü,
  • konuşlandırılan yapının çalışacağı somut ortamı tanımlayan yapının dağıtım hedefi ( örneğin , konuşması gereken bir küme ve uç noktalar)
  • diğer uç noktalara ( örn. veritabanları) bağlanmak için kullanması gereken kimlik bilgileri
  • çalışma zamanı yapılandırması (önbellek girişlerinin ne kadar süre yaşayacağı gibi)

Operasyonel açıdan, parametrenin bu dökümü, çalışma zamanı yapılandırmasıyla birlikte paketlenebilecek kimlik bilgilerinin yanı sıra, dağıtım sorununun doğal özgürlük dereceleriyle eşleşir, ancak dikkatsizce yayılmamak için bunları ayırmak daha iyidir.


5

Bout docker'a cevap verebilirim, docker'ı kullanmanın en iyi uygulamalarından biri docker dosyasını ve oluşturma dosyalarını projenin aynı havuzunda tutmaktır, böylece projeyi klonladığınız her yerde docker görüntüsünü oluşturabilirsiniz ve docker'ın birden fazla sürümünü örneğin dosya oluşturma (prod, evreleme, dev) olarak saklayın, böylece görüntüyü oluşturabilir ve her bir env için belirli bir seçenekle kapsayıcıyı çalıştırabilirsiniz.


4

Her aracın kodu kendi deposuna gider. örneğin

  1. Jenkins deposuna Jenkins Groovy şablonu
  2. Ansible YAML playbook'ları kendi repolarında (roller, görevler, envanter alt dizinleri ile)
  3. Bulut oluşturma / Terrform şablonları kendi deposunda
  4. Docker dosyaları kendi 5 .. Ve benzeri

Bu, süreç düzenlemesi ve her bir çevre için çeşitli şubeleri koruma açısından daha iyi ölçeklendirmenize yardımcı olur

Bu size daha ayrıntılı denetim sağlar ve tüm sürüm oluşturma yükünüzü sürüm kontrol sistemlerine boşaltır. Ayrıca her ortam için ayrı dallar oluşturun ve her üretim sürümü için kodu etiketleyin (uygulama kodu tabanı için yaptığımız gibi). Infra'yı düşünün ve kod açısından işleyin. (Süreçteki herhangi bir değişiklik kodlanmalı ve QA, SIT, UAT ve sonra PROD'ye gönderilmelidir) uygulamaya benzer.

Örneğin, Üretimde (ana dal) Ansible'ın V2.1'i olabilir, ancak Prod'da (ana dal) çalışan docker konteynerlerinin V2.0'ı olabilir

Benzer şekilde DB komut dosyalarınızı / bash komut dosyalarınızı kendi havuzlarında tutun ve belki de izleme ve otomatikleştirme amacıyla dağıtılan her URL'deki tüm araçların / parçaların sürümlerini gösterecek şekilde yapılandırılmış bir sağlık kontrolü dosyanız (JSON / YAML) olabilir. (Böylece web kancalarınız URL'yi okur ve dağıtımları otomatik hale getirir)


2
Bu yaklaşımın tuzağı, v2.1 qa'dadır ve onaylanmamıştır ve üretimi acilen yamalamak zorundasınız, v2.0'ı değiştiremezsiniz ve bu yama için v2.2 yaparsanız, bunun yüksek olma riski vardır. v2.1 üretime geçtiğinde kaybolan veya üzerine yazılan, bir repodaki ayrı kod miktarı ile çarpın ve yakında backportların bir kabusu var (işe yarıyor, ama bu feragatnameyi eklemek zorunda kaldım :))
Tensibai

3
Çevreye / dağıtıma özgü bilgileri takip etmek için şubeleri kullanmak benim için bir karınca deseni gibi görünüyor: 20 ortamımız varsa, bu durumda senkronize olacak 20 şubemiz var ... olası bir hata ve karışıklık kaynağı. Çevreye / dağıtıma özgü bilgileri izlemek için neden yapılandırma dosyalarını kullanmadığınızı ve iş akışınızın bu dallarla nasıl çalıştığını açıklayabilir misiniz? Bunlar önemsiz problemler değil!
Michael Le Barbier Grünewald

3

Ops, Dev ve DevOps arasında bir ayrım yapmak, izolasyonu teşvik eder ve "onu duvarın üzerinden at" zihniyetini uygular. Ekipler arasındaki işbirliğini arttırmak için, projeyi oluşturmak ve dağıtmak için gereken her şeyi bir depoya koymak gerekir.

Bunu söyledikten sonra, sorunun cevabı:

Kod deposunda DevOps ile ilgili kod ve yapılandırmalar nasıl yapılandırılır?

projeyi çalıştırmak için config gerekiyorsa, o zaman aynı dizine koymak gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.