Saya cadangkan anda membaca transkrip laporan oleh Alexander Sigachev dari Inventos "Proses pembangunan dan ujian dengan Docker + Gitlab CI"
Mereka yang baru mula melaksanakan proses pembangunan dan ujian berdasarkan Docker + Gitlab CI sering bertanya soalan asas. Di mana untuk bermula? Bagaimana untuk mengatur? Bagaimana untuk menguji?
Laporan ini bagus kerana ia bercakap secara berstruktur tentang proses pembangunan dan ujian menggunakan Docker dan Gitlab CI. Laporan itu sendiri adalah dari 2017. Saya berpendapat bahawa daripada laporan ini anda boleh mengumpul asas, metodologi, idea dan pengalaman penggunaan.
Siapa peduli, sila di bawah kucing.
Nama saya Alexander Sigachev. Saya bekerja untuk Inventos. Saya akan memberitahu anda tentang pengalaman saya menggunakan Docker dan cara kami melaksanakannya secara beransur-ansur pada projek dalam syarikat.
Topik laporan: Proses pembangunan menggunakan Docker dan Gitlab CI.
Ini adalah ceramah kedua saya tentang Docker. Pada masa laporan pertama, kami menggunakan Docker hanya dalam Pembangunan pada mesin pembangun. Bilangan pekerja yang menggunakan Docker adalah kira-kira 2-3 orang. Secara beransur-ansur, pengalaman diperoleh dan kami bergerak lebih jauh. Pautan ke kami .
Apa yang akan ada dalam laporan ini? Kami akan berkongsi pengalaman tentang apa yang kami kumpulkan, apa masalah yang kami selesaikan. Ia tidak cantik di mana-mana, tetapi ia membolehkan kami meneruskan.
Moto kami: berlabuh semua yang kami dapat.
Apakah masalah yang kita selesaikan?
Apabila syarikat mempunyai beberapa pasukan, pengaturcara adalah sumber yang dikongsi. Terdapat peringkat apabila pengaturcara ditarik keluar dari satu projek dan diberikan kepada projek lain untuk beberapa waktu.
Agar pengaturcara memahami dengan cepat, dia perlu memuat turun kod sumber projek dan melancarkan persekitaran secepat mungkin, yang akan membolehkannya untuk lebih maju dalam menyelesaikan masalah projek ini.
Biasanya, jika anda bermula dari awal, terdapat sedikit dokumentasi dalam projek itu. Hanya pemasa lama mempunyai maklumat tentang cara menyediakannya. Pekerja menyediakan tempat kerja mereka sendiri dalam satu atau dua hari. Untuk mempercepatkan ini, kami menggunakan Docker.
Sebab seterusnya ialah penyeragaman tetapan dalam Pembangunan. Mengikut pengalaman saya, pembangun sentiasa mengambil inisiatif. Dalam setiap kes kelima, domain tersuai dimasukkan, contohnya vasya.dev. Duduk di sebelah saya ialah jiran saya Petya, yang domainnya ialah petya.dev. Mereka membangunkan laman web atau beberapa komponen sistem menggunakan nama domain ini.
Apabila sistem berkembang dan nama domain ini mula dimasukkan dalam konfigurasi, konflik dalam persekitaran Pembangunan timbul dan laluan tapak ditulis semula.
Perkara yang sama berlaku dengan tetapan pangkalan data. Sesetengah orang tidak peduli dengan keselamatan dan bekerja dengan kata laluan root kosong. Pada peringkat pemasangan, MySQL meminta seseorang untuk kata laluan dan kata laluan ternyata 123. Selalunya berlaku bahawa konfigurasi pangkalan data sentiasa berubah bergantung pada komitmen pembangun. Seseorang membetulkan, seseorang tidak membetulkan konfigurasi. Terdapat helah apabila kami meletakkan beberapa konfigurasi ujian .gitignore dan setiap pembangun perlu memasang pangkalan data. Ini menjadikan proses permulaan lebih sukar. Antara lain, anda perlu ingat tentang pangkalan data. Pangkalan data mesti dimulakan, kata laluan mesti didaftarkan, pengguna mesti didaftarkan, tanda mesti dibuat, dan sebagainya.
Masalah lain ialah versi perpustakaan yang berbeza. Selalunya berlaku bahawa pemaju bekerja pada projek yang berbeza. Terdapat projek Legacy, yang bermula lima tahun lalu (dari 2017 - nota editor). Pada permulaan kami bermula dengan MySQL 5.5. Terdapat juga projek moden di mana kami cuba melaksanakan versi MySQL yang lebih moden, contohnya 5.7 atau lebih lama (pada 2017 - nota editor)
Sesiapa sahaja yang bekerja dengan MySQL tahu bahawa perpustakaan ini membawa kebergantungan. Ia agak bermasalah untuk menjalankan 2 pangkalan data bersama-sama. Sekurang-kurangnya, adalah bermasalah untuk menyambungkan pelanggan lama ke pangkalan data baharu. Ini seterusnya menimbulkan beberapa masalah.
Masalah seterusnya ialah apabila pembangun bekerja pada mesin tempatan, dia menggunakan sumber tempatan, fail tempatan, RAM tempatan. Semua interaksi pada masa membangunkan penyelesaian kepada masalah dijalankan dalam rangka kerja fakta bahawa ia berfungsi pada satu mesin. Contohnya ialah apabila kami mempunyai pelayan belakang dalam Pengeluaran 3, dan pembangun menyimpan fail ke direktori akar dan dari sana nginx mengambil fail untuk bertindak balas kepada permintaan. Apabila kod tersebut masuk ke dalam Pengeluaran, ternyata fail itu ada pada salah satu daripada 3 pelayan.
Hala tuju perkhidmatan mikro sedang berkembang. Apabila kami membahagikan aplikasi besar kami kepada beberapa komponen kecil yang berinteraksi antara satu sama lain. Ini membolehkan anda memilih teknologi untuk timbunan tugas tertentu. Ini juga membolehkan anda membahagikan kerja dan bidang tanggungjawab antara pemaju.
Pembangun bahagian hadapan, membangun dalam JS, hampir tidak mempunyai pengaruh pada bahagian belakang. Pembangun bahagian belakang, seterusnya, membangunkan, dalam kes kami, Ruby on Rails dan tidak mengganggu Frondend. Interaksi dilakukan menggunakan API.
Sebagai bonus, menggunakan Docker kami dapat mengitar semula sumber pada Pementasan. Setiap projek, disebabkan kekhususannya, memerlukan tetapan tertentu. Secara fizikal, adalah perlu untuk memperuntukkan sama ada pelayan maya dan mengkonfigurasinya secara berasingan, atau membahagikan beberapa jenis persekitaran berubah-ubah dan projek boleh mempengaruhi satu sama lain, bergantung pada versi perpustakaan.
Alatan. Apa yang kita gunakan?
- Docker sendiri. Fail Docker menerangkan kebergantungan satu aplikasi.
- Docker-compose ialah himpunan yang menghimpunkan beberapa aplikasi Docker kami.
- Kami menggunakan GitLab untuk menyimpan kod sumber.
- Kami menggunakan GitLab-CI untuk penyepaduan sistem.
Laporan terdiri daripada dua bahagian.
Bahagian pertama akan memberitahu anda cara menjalankan Docker pada mesin pembangun.
Bahagian kedua akan bercakap tentang cara berinteraksi dengan GitLab, cara kami menjalankan ujian dan cara kami melancarkan Pementasan.
Docker ialah teknologi yang membenarkan (menggunakan pendekatan deklaratif) untuk menerangkan komponen yang diperlukan. Ini adalah contoh Dockerfile. Di sini kami mengisytiharkan bahawa kami mewarisi daripada imej Docker rasmi Ruby:2.3.0. Ia mengandungi Ruby versi 2.3 yang dipasang. Kami memasang perpustakaan pemasangan yang diperlukan dan NodeJS. Kami menerangkan bahawa kami sedang mencipta direktori /app. Kami menetapkan direktori apl sebagai direktori kerja. Dalam direktori ini kami meletakkan Gemfile minimum yang diperlukan dan Gemfile.lock. Kemudian kami membina projek yang memasang imej pergantungan ini. Kami menunjukkan bahawa bekas akan bersedia untuk mendengar pada port luaran 3000. Perintah terakhir ialah arahan yang melancarkan aplikasi kami secara langsung. Jika kita melaksanakan arahan projek run, aplikasi akan cuba menjalankan dan menjalankan arahan yang ditentukan.
Ini ialah contoh minimum fail karang docker. Dalam kes ini, kami menunjukkan bahawa terdapat hubungan antara dua bekas. Ini terus ke dalam perkhidmatan pangkalan data dan perkhidmatan web. Aplikasi web kami dalam kebanyakan kes memerlukan beberapa jenis pangkalan data sebagai bahagian belakang untuk menyimpan data. Memandangkan kami menggunakan MySQL, contohnya adalah dengan MySQL - tetapi tiada apa yang menghalang kami daripada menggunakan beberapa pangkalan data lain (PostgreSQL, Redis).
Kami mengambil imej MySQL 5.7.14 tanpa perubahan daripada sumber rasmi daripada hab Docker. Kami mengumpul imej yang bertanggungjawab untuk aplikasi web kami daripada direktori semasa. Semasa pelancaran pertama, dia mengumpul imej untuk kami. Kemudian ia menjalankan arahan yang kami laksanakan di sini. Jika kita kembali, kita akan melihat bahawa arahan pelancaran ditakrifkan melalui Puma. Puma ialah perkhidmatan yang ditulis dalam Ruby. Dalam kes kedua kita menimpa. Perintah ini boleh sewenang-wenangnya bergantung pada keperluan atau tugas kita.
Kami juga menerangkan bahawa kami perlu memajukan port pada mesin hos pembangun kami dari 3000 hingga 3000 port kontena. Ini dilakukan secara automatik menggunakan iptables dan mekanismenya sendiri, yang dibenamkan secara langsung dalam Docker.
Pembangun boleh, seperti sebelum ini, mengakses mana-mana alamat IP yang tersedia, contohnya, 127.0.0.1 alamat IP tempatan atau luaran mesin.
Baris terakhir mengatakan bahawa bekas web bergantung pada bekas db. Apabila kami memanggil bekas web untuk dilancarkan, docker-compose akan mula-mula melancarkan pangkalan data untuk kami. Sudah pada permulaan pangkalan data (sebenarnya, selepas pelancaran kontena! Ini tidak menjamin kesediaan pangkalan data) ia akan melancarkan aplikasi kami, bahagian belakang kami.
Ini membolehkan kami mengelakkan ralat apabila pangkalan data tidak tersedia dan membolehkan kami menyimpan sumber apabila kami menghentikan bekas pangkalan data, dengan itu membebaskan sumber untuk projek lain.
Apakah yang diberikan kepada kami menggunakan dockerization pangkalan data pada projek? Kami merekodkan versi MySQL untuk semua pembangun. Ini membolehkan anda mengelakkan beberapa ralat yang mungkin berlaku apabila versi berbeza, apabila sintaks, konfigurasi dan tetapan lalai berubah. Ini membolehkan anda menentukan nama hos biasa untuk pangkalan data, log masuk, kata laluan. Kami beralih daripada zoo nama dan konflik dalam fail konfigurasi yang wujud sebelum ini.
Kami mempunyai peluang untuk menggunakan konfigurasi yang lebih optimum untuk persekitaran Pembangunan, yang akan berbeza daripada yang lalai. MySQL dikonfigurasikan secara lalai untuk mesin yang lemah dan prestasinya di luar kotak adalah sangat rendah.
Docker membenarkan anda menggunakan penterjemah Python, Ruby, NodeJS, PHP versi yang dikehendaki. Kami menyingkirkan keperluan untuk menggunakan beberapa jenis pengurus versi. Sebelum ini, pakej rpm telah digunakan untuk Ruby, yang membolehkan anda menukar versi bergantung pada projek. Terima kasih kepada bekas Docker, ini juga membolehkan anda memindahkan kod dan versinya dengan lancar bersama-sama dengan kebergantungan. Kami tidak mempunyai masalah untuk memahami versi kedua-dua jurubahasa dan kod. Untuk mengemas kini versi, anda perlu menurunkan bekas lama dan menaikkan bekas baharu. Jika berlaku masalah, kita boleh turunkan bekas baru, naikkan bekas lama.
Selepas membina imej, bekas dalam Pembangunan dan Pengeluaran akan menjadi sama. Ini benar terutamanya untuk pemasangan besar.
Di Frontend kami menggunakan JavaScipt dan NodeJS.
Kini kami mempunyai projek terakhir kami di ReacJS. Pembangun melancarkan segala-galanya dalam bekas dan dibangunkan menggunakan muat semula panas.
Seterusnya, tugas memasang JavaScipt dilancarkan dan kod yang dipasang secara statik dihantar melalui nginx, menjimatkan sumber.
Di sini saya telah menyediakan gambar rajah projek terbaru kami.
Apakah masalah yang anda selesaikan? Kami mempunyai keperluan untuk membina sistem dengan peranti mudah alih berinteraksi. Mereka menerima data. Salah satu kemungkinannya ialah menghantar pemberitahuan tolak ke peranti ini.
Apa yang telah kita lakukan untuk ini?
Kami membahagikan aplikasi kepada komponen berikut: bahagian pentadbir dalam JS, bahagian belakang yang berfungsi melalui antara muka REST di bawah Ruby on Rails. Backend berinteraksi dengan pangkalan data. Hasil yang dijana diberikan kepada pelanggan. Panel pentadbir berinteraksi dengan bahagian belakang dan pangkalan data melalui antara muka REST.
Kami juga mempunyai keperluan untuk menghantar pemberitahuan Tolak. Sebelum ini, kami mempunyai projek di mana mekanisme dilaksanakan yang bertanggungjawab untuk menyampaikan pemberitahuan kepada platform mudah alih.
Kami telah membangunkan skema berikut: pengendali dari penyemak imbas berinteraksi dengan panel pentadbir, panel pentadbir berinteraksi dengan bahagian belakang, tugasnya adalah untuk menghantar pemberitahuan Push.
Pemberitahuan tolak berinteraksi dengan komponen lain yang dilaksanakan dalam NodeJS.
Baris gilir dibina dan pemberitahuan dihantar mengikut mekanisme mereka sendiri.
Dua pangkalan data dilukis di sini. Pada masa ini, menggunakan Docker, kami menggunakan 2 pangkalan data bebas yang sama sekali tidak bersambung antara satu sama lain. Sebagai tambahan kepada fakta bahawa mereka mempunyai rangkaian maya biasa, dan data fizikal disimpan dalam direktori yang berbeza pada mesin pembangun.
Perkara yang sama tetapi dalam bilangan. Penggunaan semula kod adalah penting di sini.
Jika sebelum ini kita bercakap tentang menggunakan semula kod dalam bentuk perpustakaan, maka dalam contoh ini perkhidmatan kami, yang bertindak balas kepada pemberitahuan Push, digunakan semula sebagai pelayan lengkap. Ia menyediakan API. Dan perkembangan baharu kami berinteraksi dengannya.
Pada masa itu kami menggunakan versi 4 NodeJS. Sekarang (pada 2017 - nota editor) dalam perkembangan terkini kami, kami menggunakan versi 7 NodeJS. Tiada masalah dalam komponen baharu untuk melibatkan versi baharu perpustakaan.
Jika perlu, anda boleh memfaktorkan semula dan menaikkan versi NodeJS perkhidmatan pemberitahuan Push.
Dan jika kita boleh mengekalkan keserasian API, maka ia mungkin untuk menggantikannya dengan projek lain yang digunakan sebelum ini.
Apa yang anda perlukan untuk menambah Docker? Kami menambah fail Docker pada repositori kami, yang menerangkan kebergantungan yang diperlukan. Dalam contoh ini, komponen dibahagikan secara logik. Ini ialah kit minimum untuk pembangun bahagian belakang.
Apabila mencipta projek baharu, kami mencipta Dockerfile dan menerangkan ekosistem yang diperlukan (Python, Ruby, NodeJS). Dalam docker-compose, ia menerangkan pergantungan yang diperlukan - pangkalan data. Kami menerangkan bahawa kami memerlukan pangkalan data versi ini dan ini, untuk menyimpan data di sana sini.
Kami menggunakan bekas ketiga yang berasingan dengan nginx untuk menyampaikan kandungan statik. Ia adalah mungkin untuk memuat naik gambar. Bahagian belakang meletakkannya dalam volum yang telah disediakan sebelumnya, yang juga dipasang dalam bekas dengan nginx, yang menyediakan data statik.
Untuk menyimpan konfigurasi nginx dan mysql, kami menambah folder Docker di mana kami menyimpan konfigurasi yang diperlukan. Apabila pembangun membuat klon git repositori pada mesinnya, dia sudah mempunyai projek sedia untuk pembangunan tempatan. Tiada persoalan tentang port mana atau tetapan yang hendak digunakan.
Seterusnya kami mempunyai beberapa komponen: pentadbir, info-API, pemberitahuan tolak.
Untuk melancarkan semua ini, kami mencipta satu lagi repositori yang dipanggil dockerized-app. Pada masa ini kami menggunakan berbilang repositori untuk setiap komponen. Mereka secara logiknya berbeza - dalam GitLab ia kelihatan seperti folder, tetapi pada mesin pembangun ia kelihatan seperti folder untuk projek tertentu. Satu tahap di bawah adalah komponen yang akan digabungkan.
Ini ialah contoh kandungan aplikasi dockerized. Kami juga meletakkan direktori Docker di sini, di mana kami mengisi konfigurasi yang diperlukan untuk interaksi semua komponen. Terdapat README.md yang menerangkan secara ringkas cara melancarkan projek.
Di sini kami telah menggunakan dua fail karang docker. Ini dilakukan agar dapat dilancarkan secara berperingkat. Apabila pembangun bekerja dengan kernel, dia tidak memerlukan pemberitahuan Push, dia hanya melancarkan fail docker-compose dan, dengan itu, sumber disimpan.
Jika terdapat keperluan untuk penyepaduan dengan pemberitahuan Push, maka docker-compose.yaml dan docker-compose-push.yaml dilancarkan.
Memandangkan docker-compose.yaml dan docker-compose-push.yaml berada dalam folder, satu rangkaian maya dicipta secara automatik.
Penerangan komponen. Ini adalah fail yang lebih maju yang bertanggungjawab untuk mengumpul komponen. Apa yang luar biasa di sini? Di sini kami memperkenalkan komponen pengimbang.
Ini ialah imej Docker siap pakai yang menjalankan nginx dan aplikasi yang mendengar soket Docker. Dinamik, apabila bekas dihidupkan dan dimatikan, konfigurasi nginx dijana semula. Kami mengedarkan pengendalian komponen menggunakan nama domain peringkat ketiga.
Untuk persekitaran Pembangunan kami menggunakan domain .dev - api.informer.dev. Aplikasi dengan domain .dev tersedia pada mesin tempatan pembangun.
Kemudian konfigurasi dipindahkan ke setiap projek dan semua projek dilancarkan bersama-sama pada masa yang sama.
Jika kami menggambarkannya secara grafik, ternyata pelanggan adalah penyemak imbas kami atau sejenis alat yang kami gunakan untuk membuat permintaan kepada pengimbang.
Pengimbang menentukan bekas yang perlu diakses berdasarkan nama domain.
Ini mungkin nginx, yang menyediakan JS kepada panel pentadbir. Ini boleh dilakukan oleh nginx, yang menyediakan API, atau fail statik, yang disediakan oleh nginx dalam bentuk memuatkan imej.
Rajah menunjukkan bahawa bekas disambungkan ke rangkaian maya dan tersembunyi di sebalik proksi.
Pada mesin pembangun, anda boleh mengakses kontena yang mengetahui IP, tetapi pada dasarnya kami tidak menggunakan ini. Tidak ada keperluan untuk hubungan langsung.
Apakah contoh yang perlu saya lihat untuk melabuhkan permohonan saya? Pada pendapat saya, contoh yang baik ialah imej docker rasmi untuk MySQL.
Ia agak rumit. Terdapat banyak versi. Tetapi fungsinya membolehkan anda menampung banyak keperluan yang mungkin timbul dalam proses pembangunan selanjutnya. Jika anda meluangkan masa dan memahami cara semuanya berinteraksi, maka saya fikir anda tidak akan menghadapi sebarang masalah untuk melaksanakannya sendiri.
Hub.docker.com biasanya mengandungi pautan ke github.com, di mana data mentah disediakan terus dari mana anda boleh membina imej sendiri.
Selanjutnya dalam repositori ini terdapat skrip docker-endpoint.sh, yang bertanggungjawab untuk pemulaan awal dan pemprosesan lanjut pelancaran aplikasi.
Juga dalam contoh ini terdapat kemungkinan konfigurasi menggunakan pembolehubah persekitaran. Dengan mentakrifkan pembolehubah persekitaran apabila menjalankan satu bekas atau melalui docker-compose, kita boleh mengatakan bahawa kita perlu menetapkan kata laluan kosong untuk docker untuk root pada MySQL atau apa sahaja yang kita mahu.
Terdapat pilihan untuk membuat kata laluan rawak. Kami mengatakan bahawa kami memerlukan pengguna, kami perlu menetapkan kata laluan untuk pengguna, dan kami perlu mencipta pangkalan data.
Dalam projek kami, kami telah menyatukan sedikit Dockerfile, yang bertanggungjawab untuk permulaan. Di sana kami menyesuaikannya dengan keperluan kami untuk mengembangkan hak pengguna yang digunakan oleh aplikasi. Ini membolehkan anda mencipta pangkalan data daripada konsol aplikasi pada masa hadapan. Aplikasi Ruby mempunyai arahan untuk mencipta, mengubah suai dan memadam pangkalan data.
Ini adalah contoh rupa versi MySQL tertentu di github.com. Anda boleh membuka Dockerfile dan melihat cara pemasangan berlaku di sana.
skrip docker-endpoint.sh bertanggungjawab untuk titik masuk. Semasa permulaan permulaan, beberapa tindakan penyediaan diperlukan dan semua tindakan ini disertakan dalam skrip permulaan.
Mari kita teruskan ke bahagian kedua.
Kami bertukar kepada gitlab untuk menyimpan kod sumber. Ini adalah sistem yang cukup berkuasa yang mempunyai antara muka visual.
Salah satu komponen Gitlab ialah Gitlab CI. Ia membolehkan anda menerangkan satu siri perintah yang kemudiannya akan digunakan untuk mengatur sistem penghantaran kod atau menjalankan ujian automatik.
Laporan tentang Gitlab CI 2 β laporan daripada kelab Ruby Russia agak terperinci dan mungkin menarik minat anda.
Sekarang kita akan melihat apa yang diperlukan untuk mengaktifkan Gitlab CI. Untuk melancarkan Gitlab CI, kami hanya perlu meletakkan fail .gitlab-ci.yml dalam akar projek.
Di sini kami menerangkan bahawa kami ingin melaksanakan urutan keadaan seperti ujian, penggunaan.
Kami melaksanakan skrip yang secara langsung memanggil binaan docker-compose aplikasi kami. Ini adalah contoh hanya bahagian belakang.
Seterusnya kami mengatakan bahawa adalah perlu untuk menjalankan migrasi untuk menukar pangkalan data dan menjalankan ujian.
Jika skrip dilaksanakan dengan betul dan tidak mengembalikan kod ralat, maka sistem akan meneruskan ke peringkat kedua penggunaan.
Peringkat penempatan sedang dilaksanakan untuk pementasan. Kami tidak menganjurkan permulaan semula tanpa masa rehat.
Kami memadamkan semua bekas secara paksa, dan kemudian kami menaikkan semula semua bekas, dikumpulkan pada peringkat pertama semasa ujian.
Mari jalankan migrasi pangkalan data yang telah ditulis oleh pembangun untuk persekitaran pembolehubah semasa.
Terdapat nota bahawa ini hanya boleh digunakan pada cawangan induk.
Tidak berfungsi apabila menukar cawangan lain.
Adalah mungkin untuk menganjurkan pelancaran di sepanjang cawangan.
Untuk mengatur ini lebih lanjut, kita perlu memasang Gitlab Runner.
Utiliti ini ditulis dalam Golang. Ia adalah satu fail seperti biasa di dunia Golang, yang tidak memerlukan sebarang kebergantungan.
Pada permulaan kami mendaftarkan Gitlab Runner.
Kami menerima kunci dalam antara muka web Gitlab.
Kemudian kami memanggil arahan inisialisasi pada baris arahan.
Mengkonfigurasi Gitlab Runner dalam mod dialog (Shell, Docker, VirtualBox, SSH)
Kod pada Gitlab Runner akan dilaksanakan pada setiap komit bergantung pada tetapan .gitlab-ci.yml.
Bagaimana ia kelihatan secara visual dalam Gitlab dalam antara muka web. Selepas menyambung GItlab CI, kami mempunyai bendera yang menunjukkan keadaan binaan itu pada masa ini.
Kami melihat bahawa 4 minit yang lalu komitmen telah dibuat yang melepasi semua ujian dan tidak menyebabkan sebarang masalah.
Kita boleh melihat binaan dengan lebih terperinci. Di sini kita melihat bahawa dua negeri telah pun berlalu. Menguji status dan status penempatan pada pementasan.
Jika kita mengklik pada binaan tertentu, akan terdapat output konsol bagi arahan yang dilancarkan dalam proses mengikut .gitlab-ci.yml.
Beginilah rupa cerita produk kami. Kami melihat bahawa terdapat percubaan yang berjaya. Apabila ujian diserahkan, mereka tidak bergerak ke langkah seterusnya dan kod pementasan tidak dikemas kini.
Apakah masalah yang kami selesaikan dalam pementasan apabila kami melaksanakan docker? Sistem kami terdiri daripada komponen dan kami hanya perlu memulakan semula beberapa komponen yang dikemas kini dalam repositori, dan bukan keseluruhan sistem.
Untuk melakukan ini, kami terpaksa mengasingkan semuanya ke dalam folder berasingan.
Selepas kami melakukan ini, kami menghadapi masalah dengan fakta bahawa Docker-compose mencipta ruang rangkaiannya sendiri untuk setiap folder dan tidak melihat komponen jirannya.
Untuk bersiar-siar, kami mencipta rangkaian secara manual dalam Docker. Dalam Docker-compose telah ditulis bahawa anda harus menggunakan rangkaian sedemikian untuk projek ini.
Oleh itu, setiap komponen yang bermula dengan mesh ini melihat komponen di bahagian lain sistem.
Masalah seterusnya ialah membahagikan pementasan antara beberapa projek.
Oleh kerana untuk semua ini kelihatan cantik dan sedekat mungkin dengan pengeluaran, adalah baik untuk menggunakan port 80 atau 443, yang digunakan di mana-mana dalam WEB.
Bagaimana kami menyelesaikannya? Kami menugaskan satu Gitlab Runner untuk semua projek besar.
Gitlab membolehkan anda melancarkan beberapa Pelari Gitlab yang diedarkan, yang hanya akan mengambil semua tugas satu demi satu dalam susunan huru-hara dan menjalankannya.
Untuk mengelakkan masalah rumah, kami mengehadkan kumpulan projek kami kepada satu Gitlab Runner, yang mengatasi volum kami tanpa masalah.
Kami memindahkan nginx-proxy ke dalam skrip pelancaran yang berasingan dan menulis grid semua projek di dalamnya.
Projek kami mempunyai satu grid, dan pengimbang mempunyai beberapa grid berdasarkan nama projek. Ia boleh proksi lebih jauh dengan nama domain.
Permintaan kami datang melalui domain pada port 80 dan diselesaikan kepada sekumpulan kontena yang menyediakan domain ini.
Apakah masalah lain yang ada? Inilah yang dijalankan oleh semua bekas sebagai akar secara lalai. Ini ialah hos akar yang tidak sama rata bagi sistem.
Walau bagaimanapun, jika anda memasukkan bekas, ia akan menjadi akar dan fail yang kami cipta dalam bekas ini menerima hak akar.
Jika pembangun memasuki bekas dan membuat beberapa arahan di sana yang menghasilkan fail, kemudian meninggalkan bekas, maka dalam direktori kerjanya dia mempunyai fail yang dia tidak mempunyai akses.
Bagaimanakah perkara ini boleh diselesaikan? Anda boleh menambah pengguna yang akan berada di dalam bekas.
Apakah masalah yang timbul apabila kami menambah pengguna?
Apabila membuat pengguna, ID kumpulan (UID) dan ID pengguna (GID) selalunya tidak sepadan.
Untuk menyelesaikan masalah ini dalam bekas kami menggunakan pengguna dengan ID 1000.
Dalam kes kami, ini bertepatan dengan fakta bahawa hampir semua pemaju menggunakan OS Ubuntu. Dan dalam OS Ubuntu pengguna pertama mempunyai ID 1000.
Adakah kita mempunyai rancangan?
Baca semula dokumentasi Docker. Projek ini sedang giat membangun, dokumentasi sedang berubah. Data yang diperoleh dua atau tiga bulan lalu perlahan-lahan menjadi lapuk.
Beberapa masalah yang kami selesaikan mungkin telah diselesaikan dengan cara standard.
Saya benar-benar mahu meneruskan dan bergerak terus ke orkestrasi.
Satu contoh ialah mekanisme terbina dalam Docker yang dipanggil Docker Swarm, yang keluar dari kotak. Saya ingin melancarkan sesuatu dalam pengeluaran berdasarkan teknologi Docker Swarm.
Bekas bertelur membuat kerja dengan kayu balak menjadi menyusahkan. Sekarang kayu balak diasingkan. Mereka bertaburan dalam bekas. Salah satu tugas adalah untuk membuat akses mudah kepada log melalui antara muka web.
Sumber: www.habr.com