Saya mengusulkan untuk membaca transkrip laporan oleh Alexander Sigachev dari Inventos "Proses pengembangan dan pengujian dengan Docker + Gitlab CI"
Mereka yang baru mulai mengimplementasikan proses pengembangan dan pengujian berbasis Docker + Gitlab CI sering mengajukan pertanyaan mendasar. Di mana untuk memulai? Bagaimana mengatur? Bagaimana cara menguji?
Laporan ini bagus karena berbicara secara terstruktur tentang proses pengembangan dan pengujian menggunakan Docker dan Gitlab CI. Laporannya sendiri dari tahun 2017. Saya pikir dari laporan ini Anda dapat mempelajari dasar-dasar, metodologi, ide, pengalaman penggunaan.
Siapa yang peduli, tolong di bawah kucing.
Nama saya Alexander Sigachev. Saya bekerja untuk Inventos. Saya akan memberi tahu Anda tentang pengalaman saya menggunakan Docker dan bagaimana kami menerapkannya secara bertahap pada proyek di perusahaan.
Topik presentasi: Proses pengembangan menggunakan Docker dan Gitlab CI.
Ini adalah pembicaraan kedua saya tentang Docker. Pada saat laporan pertama, kami hanya menggunakan Docker dalam Pengembangan pada mesin pengembang. Jumlah karyawan yang menggunakan Docker sekitar 2-3 orang. Secara bertahap, pengalaman diperoleh dan kami bergerak sedikit lebih jauh. Tautan ke kami .
Apa yang akan ada dalam laporan ini? Kami akan membagikan pengalaman kami tentang penggaruk apa yang telah kami kumpulkan, masalah apa yang telah kami selesaikan. Tidak di mana-mana itu indah, tetapi dibiarkan terus berlanjut.
Moto kami adalah: tautkan semua yang bisa kami dapatkan.
Masalah apa yang kita selesaikan?
Ketika ada beberapa tim dalam sebuah perusahaan, programmer adalah sumber daya bersama. Ada tahapan ketika seorang programmer ditarik keluar dari satu proyek dan diberikan waktu untuk proyek lain.
Agar pemrogram dapat memahami dengan cepat, dia perlu mengunduh kode sumber proyek dan meluncurkan lingkungan sesegera mungkin, yang akan memungkinkannya untuk melangkah lebih jauh dalam memecahkan masalah proyek ini.
Biasanya, jika Anda memulai dari awal, maka hanya ada sedikit dokumentasi dalam proyek tersebut. Informasi tentang cara menyiapkan hanya tersedia untuk orang lama. Karyawan mengatur tempat kerja mereka sendiri dalam satu atau dua hari. Untuk mempercepat ini, kami menggunakan Docker.
Alasan selanjutnya adalah standarisasi pengaturan di Development. Menurut pengalaman saya, pengembang selalu mengambil inisiatif. Dalam setiap kasus kelima, domain khusus dimasukkan, misalnya, vasya.dev. Duduk di sebelahnya adalah tetangganya Petya, yang domainnya adalah petya.dev. Mereka mengembangkan situs web atau beberapa komponen sistem menggunakan nama domain ini.
Saat sistem tumbuh dan nama domain ini mulai masuk ke konfigurasi, konflik lingkungan Pengembangan muncul dan jalur situs ditulis ulang.
Hal yang sama terjadi dengan pengaturan basis data. Seseorang tidak peduli dengan keamanan dan bekerja dengan kata sandi root kosong. Pada tahap instalasi, MySQL meminta kata sandi kepada seseorang dan kata sandinya ternyata 123. Seringkali konfigurasi database terus berubah tergantung pada komitmen pengembang. Seseorang mengoreksi, seseorang tidak memperbaiki konfigurasi. Ada trik saat kami mengeluarkan semacam konfigurasi pengujian .gitignore dan setiap pengembang harus menginstal database. Ini membuatnya sulit untuk memulai. Perlu, antara lain, mengingat tentang database. Basis data harus diinisialisasi, kata sandi harus dimasukkan, pengguna harus didaftarkan, tabel harus dibuat, dan seterusnya.
Masalah lainnya adalah versi perpustakaan yang berbeda. Seringkali pengembang bekerja dengan proyek yang berbeda. Ada proyek Legacy yang dimulai lima tahun lalu (dari 2017 - catatan red.). Pada saat peluncuran, kami mulai dengan MySQL 5.5. Ada juga proyek modern di mana kami mencoba mengimplementasikan versi MySQL yang lebih modern, misalnya, 5.7 atau lebih lama (pada 2017 - catatan red.)
Siapa pun yang bekerja dengan MySQL tahu bahwa perpustakaan ini membawa ketergantungan. Agak bermasalah untuk menjalankan 2 pangkalan secara bersamaan. Setidaknya, klien lama bermasalah untuk terhubung ke database baru. Hal ini pada gilirannya menciptakan beberapa masalah.
Masalah selanjutnya adalah ketika pengembang bekerja di mesin lokal, dia menggunakan sumber daya lokal, file lokal, RAM lokal. Semua interaksi pada saat mengembangkan solusi untuk masalah dilakukan dalam kerangka fakta bahwa ia bekerja pada satu mesin. Contohnya adalah ketika kami memiliki server backend di Production 3, dan pengembang menyimpan file ke direktori root dan dari sana nginx mengambil file untuk menanggapi permintaan tersebut. Ketika kode seperti itu masuk ke Produksi, ternyata file tersebut ada di salah satu dari 3 server.
Arah layanan mikro sedang berkembang sekarang. Saat kami membagi aplikasi besar kami menjadi beberapa komponen kecil yang berinteraksi satu sama lain. Ini memungkinkan Anda memilih teknologi untuk tumpukan tugas tertentu. Ini juga memungkinkan Anda untuk berbagi pekerjaan dan tanggung jawab antara pengembang.
Pengembang depan, yang berkembang di JS, hampir tidak memiliki pengaruh pada Backend. Pengembang backend, pada gilirannya, mengembangkan, dalam kasus kami, Ruby on Rails dan tidak mengganggu Frondend. Interaksi dilakukan dengan menggunakan API.
Sebagai bonus, dengan bantuan Docker, kami dapat mendaur ulang sumber daya di Staging. Setiap proyek, karena kekhususannya, memerlukan pengaturan tertentu. Secara fisik, perlu untuk mengalokasikan server virtual dan mengonfigurasinya secara terpisah, atau berbagi beberapa jenis lingkungan variabel dan proyek dapat, bergantung pada versi perpustakaan, saling memengaruhi.
Peralatan. Apa yang kita gunakan?
- Docker itu sendiri. Dockerfile menjelaskan dependensi dari satu aplikasi.
- Docker-compose adalah bundel yang menyatukan beberapa aplikasi Docker kami.
- Kami menggunakan GitLab untuk menyimpan kode sumber.
- Kami menggunakan GitLab-CI untuk integrasi sistem.
Laporan terdiri dari dua bagian.
Bagian pertama akan berbicara tentang bagaimana Docker dijalankan di mesin pengembang.
Bagian kedua akan membahas tentang cara berinteraksi dengan GitLab, cara kami menjalankan pengujian, dan cara meluncurkan Staging.
Docker adalah teknologi yang memungkinkan (menggunakan pendekatan deklaratif) untuk menggambarkan komponen yang diperlukan. Ini adalah contoh Dockerfile. Di sini kami menyatakan bahwa kami mewarisi dari Ruby resmi: 2.3.0 gambar Docker. Ini berisi Ruby versi 2.3 yang diinstal. Kami menginstal pustaka build dan NodeJS yang diperlukan. Kami menjelaskan bahwa kami membuat direktori /app. Tetapkan direktori aplikasi sebagai direktori kerja. Di direktori ini kami menempatkan Gemfile dan Gemfile.lock minimal yang diperlukan. Kami kemudian membangun proyek yang menginstal gambar ketergantungan ini. Kami menunjukkan bahwa wadah akan siap untuk mendengarkan pada port eksternal 3000. Perintah terakhir adalah perintah yang langsung meluncurkan aplikasi kami. Jika kita menjalankan perintah mulai proyek, aplikasi akan mencoba menjalankan dan menjalankan perintah yang ditentukan.
Ini adalah contoh minimal dari file pembuat buruh pelabuhan. Dalam hal ini, kami menunjukkan bahwa ada hubungan antara dua wadah. Ini langsung ke layanan database dan layanan web. Aplikasi web kami dalam banyak kasus memerlukan semacam database sebagai backend untuk menyimpan data. Karena kita menggunakan MySQL, contohnya dengan MySQL - tetapi tidak ada yang menghalangi kita untuk menggunakan database lain (PostgreSQL, Redis).
Kami mengambil dari sumber resmi dari hub Docker gambar MySQL 5.7.14 tanpa perubahan. Kami mengumpulkan gambar yang bertanggung jawab untuk aplikasi web kami dari direktori saat ini. Itu mengumpulkan gambar untuk kami selama peluncuran pertama. Kemudian menjalankan perintah yang kami jalankan di sini. Jika kita kembali, kita akan melihat bahwa perintah peluncuran melalui Puma telah ditentukan. Puma adalah layanan yang ditulis dalam Ruby. Dalam kasus kedua, kami mengesampingkan. Perintah ini bisa berubah-ubah tergantung kebutuhan atau tugas kita.
Kami juga menjelaskan bahwa kami perlu meneruskan port pada mesin host pengembang kami dari 3000 ke 3000 pada port kontainer. Ini dilakukan secara otomatis menggunakan iptables dan mekanismenya, yang langsung disematkan di Docker.
Pengembang juga dapat, seperti sebelumnya, mengakses alamat IP yang tersedia, misalnya, 127.0.0.1 adalah alamat IP lokal atau eksternal mesin.
Baris terakhir mengatakan bahwa wadah web bergantung pada wadah db. Saat kita memanggil awal wadah web, docker-compose pertama-tama akan memulai database untuk kita. Sudah di awal basis data (sebenarnya, setelah peluncuran wadah! Ini tidak menjamin kesiapan basis data) akan meluncurkan aplikasi, backend kami.
Ini menghindari kesalahan saat database tidak diangkat dan menghemat sumber daya saat kami menghentikan penampung database, sehingga membebaskan sumber daya untuk proyek lain.
Apa yang memberi kita penggunaan dockerisasi basis data pada proyek. Kami memperbaiki versi MySQL untuk semua pengembang. Ini menghindari beberapa kesalahan yang mungkin terjadi ketika versi menyimpang, ketika sintaks, konfigurasi, pengaturan default berubah. Ini memungkinkan Anda menentukan nama host umum untuk database, login, kata sandi. Kami menjauh dari kebun binatang nama dan konflik di file konfigurasi yang kami miliki sebelumnya.
Kami memiliki kesempatan untuk menggunakan konfigurasi yang lebih optimal untuk lingkungan Pengembangan, yang akan berbeda dari default. MySQL dikonfigurasi untuk mesin yang lemah secara default dan kinerjanya di luar kotak sangat buruk.
Docker memungkinkan Anda untuk menggunakan juru bahasa Python, Ruby, NodeJS, PHP dari versi yang diinginkan. Kami menghilangkan kebutuhan untuk menggunakan semacam pengelola versi. Sebelumnya, Ruby menggunakan paket rpm yang memungkinkan Anda mengubah versi tergantung proyeknya. Ini juga memungkinkan, berkat wadah Docker, untuk memigrasikan kode dengan lancar dan membuat versi bersama dengan dependensi. Kami tidak memiliki masalah dalam memahami versi juru bahasa dan kodenya. Untuk memperbarui versi, turunkan wadah lama dan naikkan wadah baru. Jika ada yang tidak beres, kita bisa menurunkan wadah baru, menaikkan wadah lama.
Setelah membangun citra, kontainer di Pengembangan dan Produksi akan sama. Ini terutama berlaku untuk instalasi besar.
Di Frontend kami menggunakan JavaScipt dan NodeJS.
Sekarang kami memiliki proyek terakhir di ReacJS. Pengembang menjalankan semua yang ada di wadah dan mengembangkannya menggunakan hot-reload.
Selanjutnya, tugas perakitan JavaScipt diluncurkan dan kode yang dikompilasi menjadi statika diberikan melalui sumber daya hemat nginx.
Di sini saya telah memberikan skema proyek terakhir kami.
Tugas apa yang diselesaikan? Kami memiliki kebutuhan untuk membangun sistem yang berinteraksi dengan perangkat seluler. Mereka menerima data. Salah satu kemungkinannya adalah mengirim pemberitahuan push ke perangkat ini.
Apa yang telah kita lakukan untuk ini?
Kami membagi ke dalam aplikasi komponen seperti: bagian admin di JS, backend, yang bekerja melalui antarmuka REST di bawah Ruby on Rails. Backend berinteraksi dengan database. Hasil yang dihasilkan diberikan kepada klien. Panel admin berinteraksi dengan backend dan database melalui antarmuka REST.
Kami juga harus mengirim pemberitahuan push. Sebelumnya, kami memiliki proyek yang menerapkan mekanisme yang bertanggung jawab untuk mengirimkan notifikasi ke platform seluler.
Kami telah mengembangkan skema berikut: operator dari browser berinteraksi dengan panel admin, panel admin berinteraksi dengan backend, tugasnya adalah mengirim pemberitahuan Push.
Pemberitahuan push berinteraksi dengan komponen lain yang diterapkan di NodeJS.
Antrean dibangun dan kemudian notifikasi dikirimkan sesuai dengan mekanismenya.
Dua database diambil di sini. Saat ini, dengan bantuan Docker, kami menggunakan 2 database independen yang sama sekali tidak terkait satu sama lain. Selain itu, mereka memiliki jaringan virtual yang sama, dan data fisik disimpan di berbagai direktori di mesin pengembang.
Sama tapi jumlahnya. Di sinilah penggunaan kembali kode penting.
Jika sebelumnya kami berbicara tentang penggunaan kembali kode dalam bentuk pustaka, maka dalam contoh ini layanan kami yang merespons pemberitahuan Push digunakan kembali sebagai server lengkap. Ini menyediakan API. Dan pengembangan baru kami sudah berinteraksi dengannya.
Saat itu, kami menggunakan NodeJS versi 4. Sekarang (tahun 2017 - ed. note) dalam perkembangan terakhir kami menggunakan NodeJS versi 7. Tidak ada masalah dalam komponen baru untuk melibatkan versi pustaka yang baru.
Jika perlu, Anda dapat memfaktorkan ulang dan meningkatkan versi NodeJS dari layanan pemberitahuan Push.
Dan jika kita dapat mempertahankan kompatibilitas API, maka dimungkinkan untuk menggantinya dengan proyek lain yang sebelumnya digunakan.
Apa yang Anda butuhkan untuk menambahkan Docker? Kami menambahkan Dockerfile ke repositori kami, yang menjelaskan dependensi yang diperlukan. Dalam contoh ini, komponen dipecah secara logis. Ini adalah set minimum pengembang backend.
Saat membuat proyek baru, kami membuat Dockerfile, menjelaskan ekosistem yang diinginkan (Python, Ruby, NodeJS). Dalam docker-compose, ini menjelaskan ketergantungan yang diperlukan - database. Kami menjelaskan bahwa kami membutuhkan database versi ini dan itu, menyimpan data di sana dan di sana.
Kami menggunakan wadah ketiga yang terpisah dengan nginx untuk melayani statis. Dimungkinkan untuk mengunggah gambar. Backend menempatkannya dalam volume yang telah disiapkan sebelumnya, yang juga dipasang dalam wadah dengan nginx, yang memberikan statis.
Untuk menyimpan nginx, konfigurasi mysql, kami menambahkan folder Docker tempat kami menyimpan konfigurasi yang diperlukan. Saat pengembang melakukan git clone dari repositori di mesinnya, dia sudah memiliki proyek yang siap untuk pengembangan lokal. Tidak ada pertanyaan port apa atau pengaturan apa yang diterapkan.
Selanjutnya, kami memiliki beberapa komponen: admin, inform-API, notifikasi push.
Untuk memulai semua ini, kami membuat repositori lain, yang kami sebut dockerized-app. Saat ini kami menggunakan beberapa repositori sebelum setiap komponen. Mereka hanya berbeda secara logis - di GitLab terlihat seperti folder, tetapi di mesin pengembang, folder untuk proyek tertentu. Satu tingkat ke bawah adalah komponen yang akan digabungkan.
Ini adalah contoh dari isi dockerized-app. Kami juga membawa direktori Docker ke sini, di mana kami mengisi konfigurasi yang diperlukan untuk interaksi semua komponen. Ada README.md yang secara singkat menjelaskan cara menjalankan proyek.
Di sini kami telah menerapkan dua file komposisi buruh pelabuhan. Hal ini dilakukan agar dapat berjalan secara bertahap. Saat pengembang bekerja dengan inti, dia tidak memerlukan pemberitahuan push, dia hanya meluncurkan file pembuat docker dan, karenanya, sumber daya disimpan.
Jika ada kebutuhan untuk berintegrasi dengan notifikasi push, maka docker-compose.yaml dan docker-compose-push.yaml akan diluncurkan.
Karena docker-compose.yaml dan docker-compose-push.yaml ada di folder, satu jaringan virtual dibuat secara otomatis.
Deskripsi komponen. Ini adalah file yang lebih canggih yang bertanggung jawab untuk mengumpulkan komponen. Apa yang luar biasa di sini? Di sini kami memperkenalkan komponen penyeimbang.
Ini adalah image Docker siap pakai yang menjalankan nginx dan aplikasi yang mendengarkan pada soket Docker. Dinamis, saat wadah dihidupkan dan dimatikan, ia membuat ulang konfigurasi nginx. Kami mendistribusikan penanganan komponen dengan nama domain tingkat ketiga.
Untuk lingkungan Pengembangan, kami menggunakan domain .dev - api.informer.dev. Aplikasi dengan domain .dev tersedia di mesin lokal pengembang.
Selanjutnya, konfigurasi ditransfer ke setiap proyek dan semua proyek diluncurkan bersamaan pada waktu yang bersamaan.
Secara grafis, ternyata klien adalah browser kami atau beberapa alat yang kami gunakan untuk meminta penyeimbang.
Penyeimbang nama domain menentukan penampung mana yang akan dihubungi.
Itu bisa nginx, yang memberi admin JS. Ini bisa berupa nginx, yang memberikan API, atau file statis, yang diberikan ke nginx dalam bentuk unggahan gambar.
Diagram menunjukkan bahwa kontainer dihubungkan oleh jaringan virtual dan tersembunyi di balik proxy.
Di mesin pengembang, Anda dapat mengakses wadah dengan mengetahui IP, tetapi pada prinsipnya kami tidak menggunakan ini. Praktis tidak perlu akses langsung.
Contoh mana yang harus dilihat untuk melakukan docker pada aplikasi Anda? Menurut pendapat saya, contoh yang bagus adalah image docker resmi untuk MySQL.
Ini cukup menantang. Ada banyak versi. Tetapi fungsinya memungkinkan Anda untuk memenuhi banyak kebutuhan yang mungkin timbul dalam proses pengembangan lebih lanjut. Jika Anda menghabiskan waktu dan mencari tahu bagaimana semuanya berinteraksi, saya pikir Anda tidak akan memiliki masalah dalam implementasi mandiri.
Hub.docker.com biasanya berisi tautan ke github.com, yang berisi data mentah langsung dari mana Anda dapat membuat gambar sendiri.
Lebih jauh dalam repositori ini terdapat skrip docker-endpoint.sh, yang bertanggung jawab untuk inisialisasi awal dan pemrosesan lebih lanjut dari peluncuran aplikasi.
Juga dalam contoh ini, ada kemampuan untuk mengonfigurasi menggunakan variabel lingkungan. Dengan mendefinisikan variabel lingkungan saat menjalankan satu wadah atau melalui docker-compose, kita dapat mengatakan bahwa kita perlu menyetel kata sandi kosong agar docker melakukan root pada MySQL atau apa pun yang kita inginkan.
Ada opsi untuk membuat kata sandi acak. Kami mengatakan bahwa kami membutuhkan pengguna, kami perlu menetapkan kata sandi untuk pengguna, dan kami perlu membuat database.
Dalam proyek kami, kami sedikit menyatukan Dockerfile, yang bertanggung jawab untuk inisialisasi. Di sana kami memperbaikinya sesuai kebutuhan kami untuk menjadikannya hanya perpanjangan dari hak pengguna yang digunakan aplikasi. Ini memungkinkan kami untuk membuat database dari konsol aplikasi nanti. Aplikasi Ruby memiliki perintah untuk membuat, memodifikasi, dan menghapus database.
Ini adalah contoh tampilan versi spesifik MySQL di github.com. Anda dapat membuka Dockerfile dan melihat bagaimana penginstalan berlangsung di sana.
docker-endpoint.sh adalah skrip yang bertanggung jawab atas titik masuk. Selama inisialisasi awal, beberapa langkah persiapan diperlukan, dan semua tindakan ini dilakukan hanya dalam skrip inisialisasi.
Mari kita lanjutkan ke bagian kedua.
Untuk menyimpan kode sumber, kami beralih ke gitlab. Ini adalah sistem yang cukup kuat yang memiliki antarmuka visual.
Salah satu komponen Gitlab adalah Gitlab CI. Ini memungkinkan Anda untuk mendeskripsikan urutan perintah yang nantinya akan digunakan untuk mengatur sistem pengiriman kode atau menjalankan pengujian otomatis.
Gitlab CI 2 berbicara - laporan dari klub Ruby Russia - cukup detail dan mungkin menarik bagi Anda.
Sekarang kita akan melihat apa yang diperlukan untuk mengaktifkan Gitlab CI. Untuk memulai Gitlab CI, kita hanya perlu meletakkan file .gitlab-ci.yml di root proyek.
Di sini kami menjelaskan bahwa kami ingin menjalankan urutan status seperti pengujian, penerapan.
Kami menjalankan skrip yang secara langsung memanggil docker-compose untuk membangun aplikasi kami. Ini hanyalah contoh backend.
Selanjutnya, kami mengatakan bahwa perlu menjalankan migrasi untuk mengubah database dan menjalankan pengujian.
Jika skrip dijalankan dengan benar dan tidak mengembalikan kode kesalahan, maka sistem melanjutkan ke tahap kedua penerapan.
Tahap penyebaran saat ini diterapkan untuk pementasan. Kami tidak mengatur restart zero-downtime.
Kami memadamkan semua wadah secara paksa, dan kemudian kami menaikkan kembali semua wadah yang dikumpulkan pada tahap pertama selama pengujian.
Kami menjalankan untuk variabel lingkungan saat ini migrasi basis data yang ditulis oleh pengembang.
Ada catatan bahwa ini hanya berlaku untuk cabang master.
Saat mengubah cabang lain tidak dijalankan.
Dimungkinkan untuk mengatur peluncuran berdasarkan cabang.
Untuk mengatur ini lebih lanjut, kita perlu menginstal Gitlab Runner.
Utilitas ini ditulis dalam Golang. Ini adalah satu file, seperti yang umum di dunia Golang, yang tidak memerlukan ketergantungan apa pun.
Saat startup, kami mendaftarkan Gitlab Runner.
Kami mendapatkan kunci di antarmuka web Gitlab.
Kemudian kami memanggil perintah inisialisasi pada baris perintah.
Siapkan Gitlab Runner secara interaktif (Shell, Docker, VirtualBox, SSH)
Kode pada Gitlab Runner akan dijalankan pada setiap komit, tergantung pada pengaturan .gitlab-ci.yml.
Tampilannya secara visual di Gitlab di antarmuka web. Setelah kami menghubungkan GItlab CI, kami memiliki bendera yang menunjukkan status build saat ini.
Kami melihat bahwa komit dibuat 4 menit yang lalu, yang lulus semua pengujian dan tidak menimbulkan masalah.
Kita bisa melihat lebih dekat bangunannya. Di sini kita melihat bahwa dua negara telah berlalu. Status pengujian dan status penyebaran pada pementasan.
Jika kita mengklik build tertentu, maka akan ada keluaran konsol dari perintah yang dijalankan dalam proses sesuai dengan .gitlab-ci.yml.
Seperti inilah riwayat produk kami. Kami melihat bahwa ada upaya yang berhasil. Saat tes dikirimkan, itu tidak melanjutkan ke langkah berikutnya dan kode pementasan tidak diperbarui.
Tugas apa yang kami selesaikan saat melakukan pementasan saat kami mengimplementasikan buruh pelabuhan? Sistem kami terdiri dari komponen dan kami harus memulai ulang, hanya sebagian dari komponen yang diperbarui di repositori, dan bukan keseluruhan sistem.
Untuk melakukan ini, kami harus menghancurkan semuanya ke dalam folder terpisah.
Setelah kami melakukan ini, kami memiliki masalah dengan fakta bahwa komposisi Docker membuat ruang jaringannya sendiri untuk setiap ayah dan tidak melihat komponen tetangga.
Untuk berkeliling, kami membuat jaringan di Docker secara manual. Itu ditulis dalam Docker-compose bahwa Anda menggunakan jaringan seperti itu untuk proyek ini.
Jadi, setiap komponen yang dimulai dengan jaring ini melihat komponen di bagian lain dari sistem.
Masalah berikutnya adalah membagi pementasan di beberapa proyek.
Karena agar semua ini terlihat cantik dan sedekat mungkin dengan produksi, ada baiknya menggunakan port 80 atau 443, yang digunakan di mana-mana di WEB.
Bagaimana kami menyelesaikannya? Kami telah menugaskan satu Pelari Gitlab untuk semua proyek besar.
Gitlab memungkinkan Anda untuk menjalankan beberapa Pelari Gitlab terdistribusi, yang hanya akan mengambil semua tugas secara bergantian dan menjalankannya.
Agar kami tidak memiliki rumah, kami membatasi grup proyek kami ke satu Pelari Gitlab, yang menangani volume kami tanpa masalah.
Kami memindahkan nginx-proxy ke skrip startup terpisah dan menambahkan kisi untuk semua proyek di dalamnya.
Proyek kami memiliki satu kisi, dan penyeimbang memiliki beberapa kisi dengan nama proyek. Itu dapat proksi lebih lanjut dengan nama domain.
Permintaan kami datang melalui domain pada port 80 dan diselesaikan ke dalam grup kontainer yang melayani domain ini.
Apa masalah lain yang ada? Inilah yang dijalankan semua kontainer sebagai root secara default. Ini adalah root yang tidak sama dengan host root sistem.
Namun, jika Anda memasukkan wadah, itu akan menjadi root dan file yang kami buat dalam wadah ini mendapatkan hak root.
Jika pengembang memasuki wadah dan melakukan beberapa perintah di sana yang menghasilkan file, lalu meninggalkan wadah, maka dia memiliki file di direktori kerjanya yang tidak dapat dia akses.
Bagaimana ini bisa diselesaikan? Anda dapat menambahkan pengguna yang akan berada di wadah.
Masalah apa yang muncul saat kami menambahkan pengguna?
Saat membuat pengguna, kami sering tidak memiliki ID grup (UID) dan ID pengguna (GID) yang sama.
Untuk mengatasi masalah ini di wadah, kami menggunakan pengguna dengan ID 1000.
Dalam kasus kami, ini bertepatan dengan fakta bahwa hampir semua pengembang menggunakan OS Ubuntu. Dan di Ubuntu, pengguna pertama memiliki ID 1000.
Apakah kita punya rencana?
Baca dokumentasi Docker. Proyek ini berkembang secara aktif, dokumentasinya berubah. Data yang diterima dua atau tiga bulan lalu perlahan sudah ketinggalan zaman.
Beberapa masalah yang kami pecahkan kemungkinan besar sudah diselesaikan dengan cara standar.
Jadi saya ingin melangkah lebih jauh untuk langsung ke orkestrasi.
Salah satu contohnya adalah mekanisme bawaan Docker yang disebut Docker Swarm, yang muncul begitu saja. Saya ingin menjalankan sesuatu dalam produksi berdasarkan teknologi Docker Swarm.
Wadah pemijahan membuatnya tidak nyaman untuk bekerja dengan kayu gelondongan. Sekarang log diisolasi. Mereka tersebar di seluruh kontainer. Salah satu tugasnya adalah membuat akses mudah ke log melalui antarmuka web.
Sumber: www.habr.com