Menyebarkan Symfony + Bereaksi aplikasi pada AWS melalui CI

Selamat siang, dalam artikel ini saya akan menunjukkan cara menggunakan aplikasi Symfony 4 di AWS. Ada contoh proses seperti itu dalam dokumentasi resmi, tetapi versi saya tidak sepele seperti mengunduh arsip zip dengan aplikasi. Di halaman 2019, dalam mode buruh pelabuhan, arsitektur layanan mikro dan praktik CI / CD akhirnya mulai dimasukkan dalam alat tidak hanya insinyur DevOps, tetapi juga pengembang manusia biasa. Untuk membuat artikel lebih menarik, saya menambahkan sebuah front ke React.JS, untuk menutupi kebutuhan lebih banyak orang, jika aplikasi Anda tidak menggunakan Encore - itu tidak masalah, saya akan menunjukkan bagaimana cara mengubah file Docker untuk Anda, dukungan untuk React.JS hanya memengaruhi . Siapa yang akan tertarik dengan tutorial ini? Pertama-tama, ini ditujukan untuk pengembang PHP yang ingin mengubah praktik penyebaran mereka - untuk menjauh dari kanon biasa dan menggunakan buruh pelabuhan untuk mengemas aplikasi mereka dan meletakkan gambar. Tapi Anda bisa sedikit lebih dalam, dan narasi lebih lanjut akan ditujukan untuk secara otomatis menyebarkan aplikasi dari Git melalui platform CI / CD (CircleCI akan digunakan, tetapi jika Anda tertarik dengan konfigurasi Gitlab, tulis di komentar, saya akan melampirkannya). Faktanya, sama sekali tidak penting untuk Bereaksi / PHP apakah Anda memiliki aplikasi atau, katakanlah, .NET Core, bagian ini akan menarik bagi pengembang untuk mendapatkan keterampilan otomatisasi penyebaran secara umum. Kode sumber tersedia di repositori github, tautan di akhir artikel. Ayo pergi!

Saya berasumsi bahwa Anda memiliki aplikasi Symfony Anda sendiri, tetapi untuk tujuan demonstrasi saya membuat sketsa "halo, dunia!" Berisi paket-paket berikut:

`symfony/webpack-encore-bundle symfony/form symfony/orm-pack symfony/profiler-pack symfony/security-bundle symfony/twig-bundle symfony/validator symfony/phpunit-bridge` adalah perangkat pria yang minimal. Saat ini, struktur folder harus sebagai berikut:



Sekarang Anda perlu mengkonfigurasi infrastruktur cloud Anda. Saya tidak akan fokus mendaftar dan mengaktifkan periode uji coba AWS, pada tahap ini kita perlu membuat 2 instance DB - Saya akan menggunakan 2 jenis lingkungan: STG (pementasan) untuk menguji implementasi "fitur" baru dan PROD (produksi) sebagai "pertempuran" secara langsung server Banyak artikel telah ditulis tentang manfaat dari database layanan yang dikelola, terlebih lagi, kami terutama mengejar kenyamanan bagi pengembang dalam panduan ini, oleh karena itu kami menggunakan RDS, daripada meningkatkan server database kami sendiri yang terpisah. Sebagai DBMS untuk contoh ini, saya menggunakan PostgreSQL, Anda bebas memilih yang cocok untuk Anda, buka layanan RDS dan buat 2 instance kapasitas dan volume yang Anda butuhkan. Karena file .env tersedia untuk kita "di luar kotak" di Symfony, kita akan menggunakannya, misalnya, untuk PROD, dan untuk STG kita akan membuat salinan .env.stg dan mengubah APP_ENV=dev ke APP_ENV=stg di .env.stg dan APP_ENV=dev pada APP_ENV=prod di .env , dan juga masukkan parameter koneksi .env untuk setiap instance yang dibuat.

Hebat, awal telah dibuat! Seperti yang Anda ketahui, dependensi symfony dipasang melalui komposer, untuk menginstalnya, gunakan file composer.sh, yang kami masukkan ke dalam root proyek:


Ini adalah panduan instalasi perangkat lunak dari komposer .

Sekarang, untuk masing-masing lingkungan, buat Dockerfile Anda sendiri di root proyek:


dan


File dapat digunakan "sebagaimana adanya", tidak ada makro yang digunakan untuk perubahan. Mari kita menelusuri isi Dockerfile untuk menghilangkan sentuhan "ajaib". Sebagai "dasar" kami menggunakan gambar resmi PHP 7.2.19 dengan server web Apache terintegrasi (Anda bebas untuk menggunakan pilihan Anda, mengkonfigurasi bundel dengan Nginx, dan sebagainya, dalam contoh ini saya menggunakan yang di atas sebagai yang paling, menurut saya, nyaman). Garis expose tidak penting bagi kami saat ini, dengan sendirinya tidak melakukan apa-apa, tetapi di masa depan itu akan digunakan oleh ElasticBeanstalk, yang membutuhkannya untuk digunakan dengan benar. Konstruksi berikut menggunakan pengaturan produksi yang dioptimalkan oleh PHP yang direkomendasikan oleh pabrikan, mengaktifkan mod_rewrite untuk Apache dan meningkatkan memori maksimum untuk skrip PHP dari 128 hingga 256 mb, yang diperlukan agar komposer bekerja dengan benar. Selanjutnya, kami menginstal aplikasi yang diperlukan, dependensi dan ekstensi PHP, dan segera mengonfigurasinya. Kami menetapkan folder / var / www ke direktori kerja aplikasi kami - kode sumber aplikasi kami akan disalin di sana. Karena apache, secara default, menggunakan / var / www sebagai titik masuk untuk inangnya, dan file indeks symfony terletak di / var / www / publik, kami mengubah root dokumen apache dengan konstruksi berikut. Kemudian kami memasang komposer, simpul dan benang secara berurutan (jika Anda tidak menggunakan encore / react.js dalam aplikasi Anda, maka Anda tidak perlu dua poin terakhir). Akhirnya, kami menyalin kode sumber kami dan memulai pemasangan dependensi melalui komposer untuk symfony dan benang untuk react.js. Arti Dockerfile terpisah untuk STG terletak pada instruksi kedua dari belakang untuk docker - menyalin .env.stg ke .env, sehingga file .env pada gambar STG akan berisi parameter yang relevan untuk lingkungan ini. Anda dapat secara lokal (tentu saja dengan buruh pelabuhan diinstal) mengumpulkan gambar, menjalankannya dan memastikan bahwa aplikasi berfungsi dan tidak memerlukan hal lain untuk pekerjaan ini:

 docker build -t tmp:stg -f Dockerfile.stg . docker run -p 80:80 tmp:stg 

untuk STG dan

 docker build -t tmp:prod . docker run -p 80:80 tmp:prod 

untuk PROD.
Kita dapat menggunakan EC2, mengkonfigurasi ELB / ASG, dll., Atau menggunakan ElasticBeanstalk, yang hanya hadiah bagi kita dalam hal kenyamanan. Pergi ke bagian ElasticBeanstalk dan buat aplikasi baru dengan nama dan deskripsi. Kemudian buat 2 lingkungan yang disebutkan sebelumnya: STG dan PROD, buat kedua lingkungan sebagai lingkungan server Web, tentukan "Docker" sebagai platform, dan biarkan aplikasi Sampel sebagai kode aplikasi. Penempatan ke ElasticBeanstalk dilakukan dengan mengunggah file atau instruksi proyek, biasanya dalam arsip zip. Dalam kasus kami, alurnya akan seperti ini: kami mengumpulkan gambar buruh pelabuhan dari aplikasi kami, memuatnya ke dalam repositori dan memuat instruksi alih-alih arsip sumber atau gambar buruh pelabuhan, yang memberi tahu ElasticBeanstalk untuk mengambil gambar dari server jarak jauh dan menyebarkannya. Dan semua ini otomatis.

Mari kita mulai dengan membuat repositori untuk menyimpan gambar buruh pelabuhan. Ada 2 opsi:

1 - proyek Anda bersifat pribadi, kodenya tertutup dan repositori, masing-masing, juga harus ditutup. Dalam hal ini, Anda menyimpan daftar gambar Anda sendiri di suatu tempat atau menggunakan cloud pribadi. AWS memiliki ECR untuk tujuan ini, Anda dapat membuat repositori di sana, tetapi tidak ada yang memaksa Anda untuk melakukan ini.

2 - Anda memiliki proyek sumber terbuka dan Anda dapat menggunakan dockerhub.

Dalam contoh kita, kode terbuka, tetapi saya akan menunjukkan cara menggunakan repositori tertutup, setelah memahami proses ini, menghubungkan gambar dari dockerhub tidak akan sulit. Hal pertama yang kita butuhkan adalah membuat repositori itu sendiri, setelah itu kamu akan mendapatkan URI yang unik. Narasi selanjutnya akan berlaku untuk pihak ketiga (bukan repositori AWS ECR dan integrasi mereka), untuk ECR saya akan menulis setelah itu.

Setelah membuat repositori, kita perlu masuk ke layanan ini dan ada sedikit trik ... Buka pengaturan buruh pelabuhan yang diinstal secara lokal dan periksa apakah Anda memiliki opsi untuk menyimpan kata sandi di penyimpanan eksternal yang dihapus (untuk pengguna macOS: “Simpan login buruh pelabuhan dengan aman di macOS Keychain ”), jika tidak file konfigurasi yang kita butuhkan akan kosong. Jadi, kami memberi otorisasi dalam layanan yang dipilih untuk menyimpan register gambar Anda:

 docker login -u LOGIN -p PASSWORD REGISTRY 

setelah otentikasi berhasil, konstruksi berikut akan muncul di file konfigurasi ~ / .docker / config.json:

 "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" } 

Jika tidak muncul, periksa konfigurasi buruh pelabuhan yang dijelaskan di atas lagi.

Sekarang semuanya siap untuk menyiapkan file instruksi untuk ElasticBeanstalk - Dockerrun.aws.json, kodenya akan seperti ini:


Secara umum, instruksi terlihat seperti ini: masuk menggunakan kunci yang terletak oleh KEY_PATH di BUCKET_ID penyimpanan S3, muat gambar dengan IMAGE_URL menimpa yang disimpan, mulai dengan meneruskan port 80 ke port yang sama pada wadah. Sekarang tentang konstanta yang digunakan:

BUCKET_ID adalah "backpack" yang secara otomatis dibuat untuk Anda di layanan S3, yang berbentuk elasticbeanstalk-REGION-HASH, di sinilah sistem mencari file layanan untuk ElasticBeanstalk Anda, termasuk file aplikasi yang Anda unduh menggunakan tombol "Unggah dan gunakan".

KEY_PATH - path ke file otorisasi ke repositori gambar, saya menggunakan format APP_NAME / cr.json, yaitu, dalam folder di dalam BUCKET_ID dengan nama aplikasi saya (saya membuat, jika belum) saya meletakkan file cr.json yang berisi kode yang diterima setelah otorisasi dalam register. Gambar secara lokal:


IMAGE_URL adalah URI unik dari register gambar Anda + tag gambar itu sendiri, semuanya harus jelas di sini.

Itu saja, sekarang kita dapat mengunduh file ini sebagai versi aplikasi kita di ElasticBeanstalk, dan dia akan menarik gambar yang ditentukan dan menyebarkannya.

Tetap mengotomatiskan proses ini. Dan untuk menjadi sangat menarik, saya akan menerapkan urutan langkah-langkah untuk aliran berikutnya: untuk semua yang melakukan TIDAK di cabang master, gambar akan dikumpulkan dan digunakan di lingkungan STG, dan jika kita mendorong ke master, atau lebih baik, tutup dan isi dengan permintaan penggabungan , maka kode tersebut akan digunakan pada PROD. Dengan demikian, kami mendapatkan PROD penyihir terkini, di mana semuanya harus baik-baik saja, dan cabang untuk mengembangkan dan menguji kode baru dalam STG. Untuk implementasi ini, kita memerlukan instruksi untuk mengunggah gambar yang tidak terbaru, salin Dockerrun.aws.json ke Dockerrun.aws.stg.json, dan ganti nama Dockerrun.aws.json ke Dockerrun.aws.prod.json (hanya untuk kenyamanan).

Satu-satunya hal yang membuat Dockerrun.aws.stg.json terpisah dari Dockerrun.aws.prod.json adalah IMAGE_URL:


Seperti yang saya katakan di awal artikel, saya akan menggunakan CircleCI sebagai CI / CD, yang, menurut perasaan pribadi saya, lebih cepat daripada GitlabCI jika saya menggunakan versi SaaS gratis. Free Travis akan melakukannya, tetapi karena tidak bekerja dengan repositori git pribadi, saya tidak secara khusus melakukan demo di dalamnya sehingga tidak akan ada kekecewaan ketika kesempatan seperti itu diperlukan. Saya akan meninggalkan pengaturan untuk proyek di CircleCI kepada pembaca untuk belajar sendiri, saya akan memberikan instruksi yang diperlukan untuk penyebaran sendiri - di root proyek kami, kami akan membuat folder .circleci, di dalamnya config.yml dengan konten berikut:


Saya melukis aliran itu sendiri sedikit lebih awal, di sini diterjemahkan ke dalam yaml-instructions untuk CircleCI, mari kita pergi melalui implementasi langkah-langkah spesifik. Penting untuk mencatat keberadaan variabel lingkungan yang didefinisikan untuk CI yang akan digunakan olehnya selama bekerja:

CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD diperlukan untuk mengakses penyimpanan gambar buruh pelabuhan - hal yang sama yang kami tempatkan di cr.json, hanya tanpa base64

CI_REGISTRY / CI_REGISTRY_ID membuat URL gambar unik, tanpa tag

AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY - nama-nama berbicara sendiri, ini adalah kredit AWS untuk pengguna yang atas nama CircleCI akan menyebarkan. Buka AWS IAM dan buat pengguna, tambahkan dia ke grup administrator dan hanya berikan akses terprogram. Ingat bahwa AWS_SECRET_ACCESS_KEY hanya tersedia untuk dilihat / disalin satu kali, setelah Anda mengklik tautan acara, Anda tidak akan melihatnya lagi.

Kembali ke langkah-langkah konfigurasi CircleCI. Apa sih sihirnya? Checkout memuat kode sumber dari cabang git ke direktori kerja saat ini, proses ini diulang dalam setiap pekerjaan. Dalam proses pembuatan, kami secara berurutan login ke repositori, mengumpulkan kode berdasarkan Dockerfile.stg di bawah tag XXX: dev dan mengirimkannya ke repositori. build-master melakukan hal yang sama, hanya untuk build itu menggunakan Dockerfile "normal" di bawah tag XXX: latest.

deploy-stg menginstal AWS EB CLI dan membuat profil otorisasi dalam file ~ / .aws / config, yang diperlukan agar CLI berfungsi dengan benar, kemudian menginisialisasi variabel untuk CLI - Anda harus menentukan wilayah yang Anda pilih, platform - selalu Docker dan nama aplikasi Anda. Selanjutnya, kami menyalin konten Dockerrun.aws.stg.json ke file Dockerrun.aws.json yang baru dan, menggunakan lingkungan dan wilayah tertentu, memberikan perintah untuk menyebarkan aplikasi kami menggunakan profil otorisasi yang dibuat. Secara default, sebagai hasil dari perintah ini, semua kode cabang yang dipantau akan berakhir di arsip zip, yang akan diunduh ke ElasticBeanstalk dan dibongkar di sana, tetapi operasi ini relatif mahal, oleh karena itu kami membuat file Dockerrun.aws.json yang baru, yang cukup untuk digunakan oleh kami. gambar jarak jauh, dan kita hanya perlu mengunggahnya, sebenarnya. Untuk melakukan ini, buat file .ebignore di root proyek:


File ini menggunakan sintaks .gitignore dan itu adalah .gitignore, tetapi tidak untuk Git CLI, tetapi untuk AWS EB CLI. Dalam file ini, saya memberitahu CLI untuk melewati semua file kecuali Dockerrun.aws.json. Itu saja, sekarang ketika Anda menjalankan pekerjaan deploy-stg di ElasticBeanstalk, hanya file yang kami buat akan dikirim. deploy-prod melakukan hal yang sama, hanya menyalin isi file Dockerrun.aws.prod.json ke Dockerrun.aws.json, dan yang terakhir adalah indikasi urutan pekerjaan dalam format CircleCI (deploy-stg setelah build dan deploy-prod setelah build -master), dan pada cabang mana data dicari (abaikan: - master dan hanya: - master).

Hal yang sedikit berbeda adalah dengan AWS ECR, seperti yang saya janjikan, kami akan kembali ke sana. Anda tidak perlu login jarak jauh ke ECR dan membuat file cr.json, karena ElasticBeanstalk "kenal saudara secara langsung". Dengan demikian, Dockerrun.aws.json akan terlihat berbeda - tidak akan ada blok otentikasi:


Tetapi bagaimana kemudian otentikasi akan terjadi? Faktanya adalah bahwa layanan yang mengakses ECR memiliki seperangkat hak tertentu, yang pada gilirannya didasarkan pada kebijakan keamanan tertentu. Dalam kasus kami, ketika penyebaran diluncurkan melalui AWS CLI dari server pihak ketiga (dari CI), peran "aws-elasticbeanstalk-ec2-role" digunakan, temukan di AWS IAM di bagian peran dan lampirkan kebijakan tambahan "AmazonEC2ContainerRegistryReadOnly" padanya. Sekarang mengunduh dari repositori pribadi ke "tetangganya" akan berhasil tanpa kesalahan.

Tapi ini persis memuat dari VPC yang sama, melalui CLI perintah login buruh pelabuhan juga bukan "tanpa trik": Anda perlu mendapatkan (hanya mendapatkan) kredit untuk login buruh pelabuhan melalui AWS CLI, untuk ini ada perintah

aws ecr get-login --region REGION --no-include-email

Perintah ini akan mengembalikan Anda satu baris login form buruh pelabuhan ..., cukup cantumkan, di konsol yang perlu Anda jalankan

eval $(aws ecr get-login --region EB_REGION --no-include-email)

Perintah pertama akan menerima string untuk otentikasi, dan kemudian memulai proses yang sesuai. Mengingat aturan ini untuk AWS ECR, file instruksi untuk CircleCI akan terlihat seperti ini:


docker-in-docker setup_remote_docker , . , :



, , () . «» . ( - ) , , , .

GitHub: tutorial-aws-symfony-ci