Inventos'tan Alexander Sigachev tarafından hazırlanan "Docker + Gitlab CI ile geliştirme ve test süreci" raporunun dökümünü okumayı öneriyorum.
Docker + Gitlab CI tabanlı geliştirme ve test sürecini uygulamaya yeni başlayanlar genellikle temel sorular sorarlar. Nereden başlamalı? Nasıl organize edilir? Nasıl test edilir?
Bu rapor iyidir çünkü Docker ve Gitlab CI kullanan geliştirme ve test süreci hakkında yapılandırılmış bir şekilde konuşur. Raporun kendisi 2017'den. Bu rapordan, kullanım temellerini, metodolojisini, fikrini, deneyimini öğrenebileceğinizi düşünüyorum.
Kimin umurunda, lütfen kedinin altına.
Benim adım Alexander Sigachev. Inventos'ta çalışıyorum. Size Docker kullanma deneyimimi ve bunu şirketteki projelerde kademeli olarak nasıl uyguladığımızı anlatacağım.
Sunum konusu: Docker ve Gitlab CI kullanarak geliştirme süreci.
Bu benim Docker hakkında ikinci konuşmam. İlk raporun yazıldığı sırada, Docker'ı geliştirici makinelerde yalnızca Geliştirme aşamasında kullandık. Docker kullanan çalışan sayısı 2-3 kişi civarındaydı. Yavaş yavaş deneyim kazanıldı ve biraz daha ilerledik. bizim bağlantı .
Bu raporda neler olacak? Hangi tırmıkları topladığımız, hangi sorunları çözdüğümüzle ilgili deneyimlerimizi paylaşacağız. Her yerde güzel değildi, ama devam etmesine izin verildi.
Sloganımız: elimize geçen her şeyi yerleştir.
Hangi sorunları çözüyoruz?
Bir şirkette birkaç ekip olduğunda, programcı paylaşılan bir kaynaktır. Bir programcının bir projeden çıkarıldığı ve bir süre için başka bir projeye verildiği aşamalar vardır.
Programcının hızlı bir şekilde anlaması için, projenin kaynak kodunu indirmesi ve ortamı bir an önce başlatması gerekir, bu da onun bu projenin sorunlarını çözmeye devam etmesini sağlayacaktır.
Genellikle sıfırdan başlarsanız, projede çok az belge bulunur. Nasıl kurulacağına ilişkin bilgiler yalnızca eski zamanlayıcılar tarafından kullanılabilir. Çalışanlar bir veya iki günde kendi işyerlerini kuruyorlar. Bunu hızlandırmak için Docker kullandık.
Bir sonraki neden, Geliştirme'deki ayarların standartlaştırılmasıdır. Deneyimlerime göre, geliştiriciler her zaman inisiyatif alır. Her beşinci durumda, örneğin vasya.dev gibi özel bir etki alanı girilir. Yanında etki alanı petya.dev olan komşusu Petya oturuyor. Bu alan adını kullanarak bir web sitesi veya sistemin bazı bileşenlerini geliştirirler.
Sistem büyüdüğünde ve bu alan adları konfigürasyonlara girmeye başladığında, bir Geliştirme ortamı çakışması ortaya çıkar ve site yolu yeniden yazılır.
Aynısı veritabanı ayarlarında da olur. Birisi güvenlikle uğraşmaz ve boş bir root şifresiyle çalışır. Kurulum aşamasında, MySQL birinden bir şifre istedi ve şifrenin 123 olduğu ortaya çıktı. Çoğu zaman, geliştiricinin taahhüdüne bağlı olarak veritabanı yapılandırması sürekli değişir. Birisi düzeltti, birisi yapılandırmayı düzeltmedi. Bir tür test yapılandırması çıkardığımızda hileler vardı. .gitignore ve her geliştiricinin veritabanını kurması gerekiyordu. Bu, başlamayı zorlaştırdı. Diğer şeylerin yanı sıra, veritabanı hakkında hatırlamak gereklidir. Veritabanı başlatılmalı, bir parola girilmeli, bir kullanıcı kaydedilmeli, bir tablo oluşturulmalı vb.
Başka bir sorun, kitaplıkların farklı sürümleridir. Genellikle bir geliştiricinin farklı projelerle çalıştığı görülür. Beş yıl önce başlayan bir Legacy projesi var (2017'den - ed. not). Lansman sırasında MySQL 5.5 ile başladık. MySQL'in daha modern sürümlerini, örneğin 5.7 veya daha eski sürümlerini uygulamaya çalıştığımız modern projeler de var (2017'de - baskı notu)
MySQL ile çalışan herkes, bu kitaplıkların kendileriyle birlikte bağımlılıklar getirdiğini bilir. 2 tabanı bir arada çalıştırmak oldukça problemlidir. En azından, eski istemcilerin yeni veritabanına bağlanması sorunludur. Bu da çeşitli sorunlar yaratır.
Bir sonraki sorun, bir geliştirici yerel bir makinede çalışırken yerel kaynakları, yerel dosyaları, yerel RAM'i kullanmasıdır. Problemlere çözüm geliştirme aşamasındaki tüm etkileşim, tek bir makine üzerinde çalışması çerçevesinde gerçekleştirilir. Bir örnek, Üretim 3'te arka uç sunucularımız olduğu ve geliştiricinin dosyaları kök dizine kaydettiği ve oradan nginx'in isteğe yanıt vermek için dosyaları aldığı zamandır. Böyle bir kod Üretime girdiğinde, dosyanın 3 sunucudan birinde olduğu ortaya çıkıyor.
Mikro hizmetlerin yönü şimdi gelişiyor. Büyük uygulamalarımızı birbiriyle etkileşime giren bazı küçük bileşenlere böldüğümüzde. Bu, belirli bir görev yığını için teknolojileri seçmenize olanak tanır. Ayrıca geliştiriciler arasında iş ve sorumlulukları paylaşmanıza olanak tanır.
JS üzerinde geliştirme yapan Frondend geliştiricisinin Backend üzerinde neredeyse hiçbir etkisi yoktur. Arka uç geliştiricisi de bizim durumumuzda Ruby on Rails'i geliştirir ve Frondend'e müdahale etmez. Etkileşim, API kullanılarak gerçekleştirilir.
Bonus olarak, Docker'ın yardımıyla Staging'de kaynakları geri dönüştürebildik. Her proje, özellikleri nedeniyle belirli ayarlar gerektiriyordu. Fiziksel olarak, ya bir sanal sunucu tahsis etmek ve bunları ayrı ayrı yapılandırmak ya da bir tür değişken ortamı paylaşmak gerekiyordu ve projeler, kitaplıkların sürümüne bağlı olarak birbirini etkileyebilir.
Aletler. Ne kullanıyoruz?
- Docker'ın kendisi. Dockerfile, tek bir uygulamanın bağımlılıklarını açıklar.
- Docker-compose, birkaç Docker uygulamamızı bir araya getiren bir pakettir.
- Kaynak kodunu saklamak için GitLab kullanıyoruz.
- Sistem entegrasyonu için GitLab-CI kullanıyoruz.
Rapor iki bölümden oluşmaktadır.
İlk bölüm Docker'ın geliştiricilerin makinelerinde nasıl çalıştırıldığından bahsedecek.
İkinci bölümde GitLab ile nasıl etkileşim kuracağımız, testleri nasıl yürüttüğümüz ve Staging'i nasıl kullanıma sunduğumuz hakkında konuşacağız.
Docker, (bildirimsel bir yaklaşım kullanarak) gerekli bileşenleri tanımlamaya izin veren bir teknolojidir. Bu bir örnek Docker dosyasıdır. Burada resmi Ruby:2.3.0 Docker görüntüsünden devraldığımızı beyan ederiz. Yüklü Ruby sürüm 2.3 içerir. Gerekli derleme kitaplıklarını ve NodeJS'yi kuruyoruz. Bir dizin oluşturduğumuzu açıklıyoruz /app. Uygulama dizinini çalışma dizini olarak ayarlayın. Bu dizinde gerekli minimum Gemfile ve Gemfile.lock'u yerleştiriyoruz. Daha sonra bu bağımlılık görüntüsünü kuran projeleri oluşturuyoruz. Container'ın harici port 3000'de dinlemeye hazır olacağını belirtiyoruz. Son komut uygulamamızı direk olarak başlatan komuttur. Proje başlat komutunu çalıştırırsak, uygulama belirtilen komutu çalıştırmayı ve çalıştırmayı deneyecektir.
Bu, docker-compose dosyasının minimal bir örneğidir. Bu durumda, iki konteyner arasında bir bağlantı olduğunu gösteriyoruz. Bu doğrudan veritabanı hizmetine ve web hizmetine yapılır. Web uygulamalarımız çoğu durumda veri depolamak için bir arka uç olarak bir tür veritabanı gerektirir. MySQL kullandığımız için, örnek MySQL iledir - ancak hiçbir şey bizi başka bir veritabanı (PostgreSQL, Redis) kullanmaktan alıkoyamaz.
Resmi kaynaktan Docker hub'ından MySQL 5.7.14 görüntüsünü değiştirmeden alıyoruz. Web uygulamamızdan sorumlu olan imajı mevcut dizinden topluyoruz. İlk başlatma sırasında bizim için bir görüntü toplar. Ardından burada yürüttüğümüz komutu çalıştırır. Geriye dönecek olursak Puma üzerinden launch komutunun tanımlandığını göreceğiz. Puma, Ruby ile yazılmış bir hizmettir. İkinci durumda, geçersiz kılıyoruz. Bu komut, ihtiyaçlarımıza veya görevlerimize bağlı olarak keyfi olabilir.
Ayrıca geliştirici ana makinemizde bir portu 3000'den 3000'e konteyner limanına iletmemiz gerektiğini açıklıyoruz. Bu, Docker'a doğrudan gömülü olan iptables ve mekanizması kullanılarak otomatik olarak yapılır.
Geliştirici, daha önce olduğu gibi, kullanılabilir herhangi bir IP adresine de erişebilir; örneğin, 127.0.0.1, makinenin yerel veya harici IP adresidir.
Son satır, web kabının db kabına bağlı olduğunu söylüyor. Web container'ın başlangıcını çağırdığımızda docker-compose bizim için ilk önce veritabanını başlatacak. Zaten veritabanının başlangıcında (aslında, konteynerin başlatılmasından sonra! Bu, veritabanının hazır olduğunu garanti etmez), arka ucumuz olan uygulamayı başlatacaktır.
Bu, veritabanı açılmadığında hataları önler ve veritabanı kapsayıcısını durdurduğumuzda kaynakları kurtarır, böylece diğer projeler için kaynakları serbest bırakır.
Bize projede veritabanı dockerizasyonunun kullanımını sağlayan şey. Tüm geliştiriciler için MySQL sürümünü düzeltiyoruz. Bu, sürümler farklılaştığında, sözdizimi, yapılandırma, varsayılan ayarlar değiştiğinde oluşabilecek bazı hataları önler. Bu, veritabanı, oturum açma ve parola için ortak bir ana bilgisayar adı belirlemenizi sağlar. Daha önce sahip olduğumuz yapılandırma dosyalarındaki adlar ve çatışmalar hayvanat bahçesinden uzaklaşıyoruz.
Geliştirme ortamı için varsayılandan farklı olacak daha uygun bir yapılandırma kullanma fırsatımız var. MySQL, varsayılan olarak zayıf makineler için yapılandırılmıştır ve kutudan çıktığı haliyle performansı çok düşüktür.
Docker, istediğiniz sürümün Python, Ruby, NodeJS, PHP yorumlayıcısını kullanmanızı sağlar. Bir çeşit sürüm yöneticisi kullanma ihtiyacından kurtulmuş oluyoruz. Daha önce Ruby, projeye bağlı olarak sürümü değiştirmenize izin veren bir rpm paketi kullanıyordu. Ayrıca, Docker kapsayıcısı sayesinde kodu sorunsuz bir şekilde taşımaya ve bağımlılıklarla birlikte sürümlendirmeye olanak tanır. Hem yorumlayıcının hem de kodun sürümünü anlamakta sorun yaşamıyoruz. Sürümü güncellemek için eski kabı indirin ve yeni kabı kaldırın. Bir şeyler ters giderse, yeni kabı indirebilir, eski kabı kaldırabiliriz.
Görüntüyü oluşturduktan sonra hem Geliştirme hem de Üretimdeki kapsayıcılar aynı olacaktır. Bu özellikle büyük tesisler için geçerlidir.
Frontend'de JavaScipt ve NodeJS kullanıyoruz.
Artık ReacJS üzerinde son projemiz var. Geliştirici kapsayıcıdaki her şeyi çalıştırdı ve çalışırken yeniden yüklemeyi kullanarak geliştirdi.
Daha sonra, JavaScipt derleme görevi başlatılır ve statik olarak derlenen kod, nginx tasarruf kaynakları aracılığıyla verilir.
Burada son projemizin şemasını verdim.
Hangi görevler çözüldü? Mobil cihazların etkileşime girdiği bir sistem kurma ihtiyacı duyduk. Veri alırlar. Bir olasılık, bu cihaza anında iletme bildirimleri göndermektir.
Bunun için ne yaptık?
Uygulamaya aşağıdaki gibi bileşenleri ayırdık: JS'deki yönetici kısmı, Ruby on Rails altında REST arayüzü aracılığıyla çalışan arka uç. Arka uç veritabanı ile etkileşime girer. Oluşturulan sonuç müşteriye verilir. Yönetici paneli, arka uç ve veritabanı ile REST arayüzü aracılığıyla etkileşime girer.
Ayrıca push bildirimleri göndermeye ihtiyacımız vardı. Bundan önce, bildirimleri mobil platformlara iletmekten sorumlu bir mekanizma uygulayan bir projemiz vardı.
Aşağıdaki şemayı geliştirdik: tarayıcıdan bir operatör yönetici paneliyle etkileşime girer, yönetici paneli arka uçla etkileşime girer, görev Push bildirimleri göndermektir.
Push bildirimleri, NodeJS'de uygulanan başka bir bileşenle etkileşime girer.
Kuyruklar oluşturulur ve ardından mekanizmalarına göre bildirimler gönderilir.
Burada iki veri tabanı çizilmiştir. Şu anda Docker yardımıyla birbiriyle hiçbir ilgisi olmayan 2 bağımsız veritabanı kullanıyoruz. Ek olarak, ortak bir sanal ağa sahiptirler ve fiziksel veriler, geliştiricinin makinesinde farklı dizinlerde depolanır.
Aynı ama sayı olarak. Kodun yeniden kullanımının önemli olduğu yer burasıdır.
Daha önce kitaplıklar biçimindeki kodu yeniden kullanmaktan bahsetmiştik, o zaman bu örnekte Push bildirimlerine yanıt veren hizmetimiz tam bir sunucu olarak yeniden kullanılıyor. Bir API sağlar. Ve yeni geliştirmemiz zaten onunla etkileşime giriyor.
O zamanlar NodeJS'nin 4. sürümünü kullanıyorduk. Şimdi (2017'de - baskı notu) son gelişmelerde NodeJS'nin 7. sürümünü kullanıyoruz. Yeni bileşenlerde, kitaplıkların yeni sürümlerini dahil etmede bir sorun yoktur.
Gerekirse, Push bildirim hizmetinden NodeJS sürümünü yeniden düzenleyebilir ve yükseltebilirsiniz.
API uyumluluğunu koruyabilirsek, daha önce kullanılan diğer projelerle değiştirmek mümkün olacaktır.
Docker'ı eklemek için neye ihtiyacınız var? Depomuza gerekli bağımlılıkları açıklayan bir Dockerfile ekliyoruz. Bu örnekte, bileşenler mantıksal olarak ayrılmıştır. Bu, bir arka uç geliştiricisinin minimum kümesidir.
Yeni bir proje oluştururken bir Dockerfile oluşturuyoruz, istenen ekosistemi (Python, Ruby, NodeJS) tanımlıyoruz. Docker-compose'da, gerekli bağımlılığı - veritabanını açıklar. Böyle ve böyle bir sürümün bir veritabanına ihtiyacımız olduğunu, verileri orada burada sakladığımızı açıklıyoruz.
Statik hizmet vermek için nginx ile ayrı bir üçüncü kapsayıcı kullanıyoruz. Resim yüklemek mümkündür. Arka uç, onları önceden hazırlanmış bir birime yerleştirir ve bu, aynı zamanda statiği veren nginx'li bir kapsayıcıya da monte edilir.
Nginx, mysql yapılandırmasını depolamak için gerekli yapılandırmaları sakladığımız bir Docker klasörü ekledik. Bir geliştirici, makinesinde bir havuzun git klonunu yaptığında, yerel geliştirmeye hazır bir projesi zaten vardır. Hangi bağlantı noktasının veya hangi ayarların uygulanacağı konusunda hiçbir soru yoktur.
Ardından, birkaç bileşenimiz var: admin, inform-API, push bildirimleri.
Tüm bunları başlatmak için dockerized-app adını verdiğimiz başka bir depo oluşturduk. Şu anda her bileşenden önce birkaç depo kullanıyoruz. Sadece mantıksal olarak farklıdırlar - GitLab'da bir klasör gibi görünür, ancak geliştiricinin makinesinde belirli bir proje için bir klasördür. Bir seviye aşağı, birleştirilecek olan bileşenlerdir.
Bu, yalnızca dockerized-app içeriğinin bir örneğidir. Tüm bileşenlerin etkileşimi için gerekli konfigürasyonları doldurduğumuz Docker dizinini de buraya getiriyoruz. Projenin nasıl çalıştırılacağını kısaca açıklayan bir README.md dosyası vardır.
Burada iki docker-compose dosyası uyguladık. Bu, adım adım koşabilmek için yapılır. Bir geliştirici çekirdek ile çalıştığında anında iletme bildirimlerine ihtiyaç duymaz, yalnızca bir docker-compose dosyasını başlatır ve buna göre kaynak kaydedilir.
Push bildirimleri ile entegrasyona ihtiyaç varsa, docker-compose.yaml ve docker-compose-push.yaml başlatılır.
docker-compose.yaml ve docker-compose-push.yaml bir klasörde olduğundan, otomatik olarak tek bir sanal ağ oluşturulur.
Bileşenlerin tanımı. Bu, bileşenlerin toplanmasından sorumlu olan daha gelişmiş bir dosyadır. Burada dikkat çekici olan nedir? Burada dengeleyici bileşeni tanıtıyoruz.
Bu, nginx çalıştıran hazır bir Docker görüntüsü ve Docker soketinde dinleme yapan bir uygulamadır. Dinamik, kapsayıcılar açılıp kapatıldığında nginx yapılandırmasını yeniden oluşturur. Bileşenlerin işlenmesini üçüncü düzey alan adlarına göre dağıtıyoruz.
Geliştirme ortamı için .dev etki alanını - api.informer.dev kullanıyoruz. .dev etki alanına sahip uygulamalar, geliştiricinin yerel makinesinde mevcuttur.
Ayrıca her projeye konfigürasyonlar aktarılır ve tüm projeler aynı anda birlikte başlatılır.
Grafik olarak, istemcinin bizim tarayıcımız veya dengeleyiciye istekte bulunduğumuz bir araç olduğu ortaya çıkıyor.
Etki alanı adı dengeleyici, hangi kapsayıcıyla iletişim kurulacağını belirler.
Yönetici JS'yi veren nginx olabilir. Bu, API'yi veren nginx veya nginx'e resim yüklemeleri şeklinde verilen statik dosyalar olabilir.
Diyagram, kapsayıcıların bir sanal ağ tarafından bağlandığını ve bir proxy'nin arkasına gizlendiğini göstermektedir.
Geliştiricinin makinesinde, konteynere IP'yi bilerek erişebilirsiniz, ancak prensipte bunu kullanmıyoruz. Doğrudan erişime neredeyse hiç gerek yoktur.
Uygulamanızı dockerize etmek için hangi örneğe bakmalı? Bence iyi bir örnek, MySQL için resmi liman işçisi görüntüsüdür.
Oldukça zorlu. Birçok versiyon var. Ancak işlevselliği, daha fazla geliştirme sürecinde ortaya çıkabilecek birçok ihtiyacı karşılamanıza olanak tanır. Zaman harcar ve her şeyin nasıl etkileşime girdiğini anlarsanız, o zaman kendi kendini uygulamada hiçbir sorun yaşamayacağınızı düşünüyorum.
Hub.docker.com genellikle doğrudan görüntüyü kendiniz oluşturabileceğiniz ham verileri içeren github.com'a bağlantılar içerir.
Bu depoda ayrıca, ilk başlatmadan ve uygulama başlatmanın daha fazla işlenmesinden sorumlu olan bir docker-endpoint.sh betiği vardır.
Ayrıca bu örnekte, ortam değişkenlerini kullanarak yapılandırma yeteneği vardır. Tek bir container çalıştırırken ya da docker-compose üzerinden ortam değişkeni tanımlayarak, docker'ın MySQL ya da her ne istiyorsak root yapması için boş bir parola belirlememiz gerektiğini söyleyebiliriz.
Rastgele bir şifre oluşturma seçeneği vardır. Bir kullanıcıya ihtiyacımız olduğunu, kullanıcı için bir şifre belirlememiz gerektiğini ve bir veritabanı oluşturmamız gerektiğini söylüyoruz.
Projelerimizde, başlatmadan sorumlu olan Dockerfile'ı biraz birleştirdik. Orada, uygulamanın kullandığı kullanıcı haklarının bir uzantısı yapmak için ihtiyaçlarımıza göre düzelttik. Bu, daha sonra uygulama konsolundan basitçe bir veritabanı oluşturmamıza izin verdi. Ruby uygulamalarının veritabanlarını oluşturmak, değiştirmek ve silmek için bir komutu vardır.
Bu, MySQL'in belirli bir sürümünün github.com'da nasıl göründüğünün bir örneğidir. Dockerfile dosyasını açıp orada kurulumun nasıl olduğunu görebilirsiniz.
docker-endpoint.sh, giriş noktasından sorumlu komut dosyasıdır. İlk başlatma sırasında, bazı hazırlık adımları gereklidir ve tüm bu eylemler, yalnızca başlatma komut dosyasında gerçekleştirilir.
İkinci kısma geçiyoruz.
Kaynak kodlarını depolamak için gitlab'e geçtik. Bu, görsel bir arayüze sahip oldukça güçlü bir sistemdir.
Gitlab'ın bileşenlerinden biri Gitlab CI'dir. Daha sonra bir kod dağıtım sistemi düzenlemek veya otomatik test yapmak için kullanılacak bir dizi komut tanımlamanıza olanak tanır.
Gitlab CI 2 konuşması - Ruby Russia kulübünden rapor - oldukça detaylı ve belki ilginizi çeker.
Şimdi Gitlab CI'yi aktif hale getirmek için nelerin gerekli olduğuna bakacağız. Gitlab CI'yi başlatmak için .gitlab-ci.yml dosyasını projenin kök dizinine koymamız yeterlidir.
Burada test, konuşlandırma gibi bir dizi durumu yürütmek istediğimizi açıklıyoruz.
Uygulamamızı oluşturmak için docker-compose'u doğrudan çağıran betikleri yürütürüz. Bu sadece bir arka uç örneğidir.
Ardından, veritabanını değiştirmek ve testleri çalıştırmak için migrasyonların çalıştırılması gerektiğini söylüyoruz.
Betikler doğru yürütülürse ve bir hata kodu döndürmezse, sistem konuşlandırmanın ikinci aşamasına geçer.
Dağıtım aşaması şu anda hazırlama için uygulanmaktadır. Sıfır kesinti süreli bir yeniden başlatma organize etmedik.
Tüm kapları zorla söndürüyoruz ve ardından test sırasında ilk aşamada toplanan tüm kapları tekrar kaldırıyoruz.
Mevcut ortam değişkeni için geliştiriciler tarafından yazılan veritabanı geçişlerini çalıştırıyoruz.
Bunun yalnızca ana dal için geçerli olduğuna dair bir not var.
Diğer şubeleri değiştirirken yürütülmez.
Dağıtımları şubelere göre organize etmek mümkündür.
Bunu daha fazla organize etmek için Gitlab Runner'ı kurmamız gerekiyor.
Bu yardımcı program Golang'da yazılmıştır. Herhangi bir bağımlılık gerektirmeyen Golang dünyasında yaygın olduğu gibi tek bir dosyadır.
Başlangıçta, Gitlab Runner'ı kaydediyoruz.
Anahtarı Gitlab web arayüzünde alıyoruz.
Ardından komut satırında başlatma komutunu çağırıyoruz.
Gitlab Runner'ı etkileşimli olarak kurun (Shell, Docker, VirtualBox, SSH)
Gitlab Runner'daki kod, .gitlab-ci.yml ayarına bağlı olarak her işlemde yürütülür.
Web arayüzünde Gitlab'da görsel olarak nasıl göründüğü. GItlab CI'yi bağladıktan sonra, yapının o anki durumunu gösteren bir bayrağımız var.
4 dakika önce tüm testleri geçen ve herhangi bir sorun çıkarmayan bir taahhüt yapıldığını görüyoruz.
Yapılara daha yakından bakabiliriz. Burada iki halin çoktan geçtiğini görüyoruz. Hazırlamada test durumu ve dağıtım durumu.
Belirli bir yapıya tıklarsak, .gitlab-ci.yml'ye göre işlemde çalıştırılan komutların bir konsol çıktısı olacaktır.
Ürün geçmişimiz böyle görünüyor. Başarılı girişimlerin olduğunu görüyoruz. Testler gönderildiğinde bir sonraki adıma geçmez ve aşamalandırma kodu güncellenmez.
Docker'ı uyguladığımızda hazırlamada hangi görevleri çözdük? Sistemimiz bileşenlerden oluşuyor ve tüm sistemi değil, depoda güncellenen bileşenlerin yalnızca bir kısmını yeniden başlatmamız gerekti.
Bunu yapmak için her şeyi ayrı klasörlere ayırmamız gerekiyordu.
Bunu yaptıktan sonra, Docker-compose'un her baba için kendi ağ alanını oluşturması ve komşunun bileşenlerini görmemesi ile ilgili bir sorun yaşadık.
Dolaşmak için, ağı Docker'da manuel olarak oluşturduk. Bu proje için böyle bir ağ kullandığınız Docker-compose'da yazılmıştır.
Böylece bu ağ ile başlayan her bileşen, sistemin diğer bölümlerindeki bileşenleri görür.
Bir sonraki sorun, aşamalandırmayı birden çok projeye bölmek.
Tüm bunların güzel görünmesi ve üretime olabildiğince yakın olması için WEB'de her yerde kullanılan 80 veya 443 numaralı bağlantı noktasını kullanmak iyidir.
Nasıl çözdük? Tüm büyük projelere bir Gitlab Runner atadık.
Gitlab, tüm görevleri sırayla kaotik bir şekilde alıp çalıştıracak olan birkaç dağıtılmış Gitlab Runner'ı çalıştırmanıza izin verir.
Bir evimiz olmaması için, proje grubumuzu hacimlerimizle sorunsuz bir şekilde başa çıkan bir Gitlab Runner ile sınırladık.
Nginx-proxy'yi ayrı bir başlangıç betiğine taşıdık ve içindeki tüm projeler için ızgaralar ekledik.
Projemizin bir ızgarası var ve dengeleyicinin proje adlarına göre birkaç ızgarası var. Alan adlarına göre daha fazla proxy yapabilir.
İsteklerimiz 80 numaralı bağlantı noktasındaki etki alanı üzerinden gelir ve bu etki alanına hizmet veren bir kapsayıcı grubuna çözümlenir.
Başka hangi sorunlar vardı? Bu, tüm kapların varsayılan olarak kök olarak çalıştığı şeydir. Bu, sistemin kök ana bilgisayarına eşit olmayan bir köktür.
Ancak container'a girerseniz root olur ve bu container'da oluşturduğumuz dosya root haklarına sahip olur.
Geliştirici kaba girdiyse ve orada dosya üreten bazı komutlar verdiyse, ardından kaptan ayrıldıysa, çalışma dizininde erişimi olmayan bir dosya vardır.
Nasıl çözülebilir? Kapsayıcıda olacak kullanıcıları ekleyebilirsiniz.
Kullanıcıyı eklediğimizde hangi sorunlar ortaya çıktı?
Bir kullanıcı oluştururken, genellikle aynı grup kimliğine (UID) ve kullanıcı kimliğine (GID) sahip değiliz.
Kapsayıcıdaki bu sorunu çözmek için ID 1000 olan kullanıcıları kullanıyoruz.
Bizim durumumuzda bu, neredeyse tüm geliştiricilerin Ubuntu işletim sistemini kullanması gerçeğiyle aynı zamana denk geldi. Ve Ubuntu'da, ilk kullanıcının kimliği 1000'dir.
Planlarımız var mı?
Docker belgelerini okuyun. Proje aktif olarak gelişiyor, belgeler değişiyor. İki veya üç ay önce alınan veriler şimdiden yavaş yavaş geçerliliğini yitiriyor.
Çözdüğümüz sorunlardan bazıları, muhtemelen zaten standart araçlarla çözülmüş durumda.
Bu yüzden doğrudan orkestrasyona gitmek için daha da ileri gitmek istiyorum.
Bir örnek, Docker'ın kutudan çıkan Docker Swarm adlı yerleşik mekanizmasıdır. Docker Swarm teknolojisine dayalı üretimde bir şey çalıştırmak istiyorum.
Oluşturma kapları, günlüklerle çalışmayı elverişsiz hale getirir. Artık günlükler izole edilmiştir. Konteynerlere dağılmış durumdalar. Görevlerden biri, web arayüzü aracılığıyla günlüklere kolay erişim sağlamaktır.
Kaynak: habr.com