Blog AWS Indonesia

AWS Copilot: Application-first CLI untuk Containers di AWS

Pada tanggal 9 Juli 2020, kami memperkenalkan AWS Copilot, antarmuka baris perintah (CLI) untuk membangun, merilis, dan mengoperasikan containerized applications yang siap dijalankan untuk production environment di Amazon Elastic Container Service (Amazon ECS) dan AWS Fargate. Dalam tulisan ini, saya akan memandu Anda untuk memahami prinsip desain dari AWS Copilot, bagaimana prinsip tersebut dipetakan ke dalam fitur Copilot, dan visi untuk Copilot ke depannya.

1. Pengguna umumnya memikirkan arsitektur, bukan infrastruktur.

Developer yang membangun microservices seharusnya tidak perlu menentukan virtual private cloud, pengaturan load balancer, atau konfigurasi pipeline yang rumit. Mereka juga tidak perlu paham secara menyeluruh tentang layanan AWS. Mereka cukup menentukan jenis layanan AWS yang dibutuhkan dan bagaimana layanan itu dapat digunakan di dalam arsitektur mereka secara keseluruhan; infrastruktur baru akan dimulai dari titik itu.

Dalam artikel “Containers and Infrastructure as Code, like peanut butter and jelly”, Clare membahas tentang bagaimana kami berpikir fase lanjutan dari Infrastruktur-as-Code (IaC) adalah arsitektur sebagai bagian dari kode. Alih-alih menentukan sumber daya AWS secara individual, dengan Copilot Anda dapat mendeklarasikan jenis layanan container yang ingin Anda jalankan. Layanan lainnya yang mendukung architecture, seperti Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Container Registry (Amazon ECR), atau load balancer, akan dibentuk oleh AWS Copilot untuk melengkapi arsitektur Anda.

Saat menjalankan copilot init atau copilot svc init, Copilot akan meminta input untuk jenis layanan yang ingin Anda bentuk. Hasilnya adalah file manifes yang dapat diikutsertakan dalam version control dan menyimpan beberapa parameter untuk melakukan konfigurasi arsitektur layanan Anda. Sebagai contoh, pola “Load Balanced Web Service” mengabstraksi pengaturan Application Load Balancer seperti listener rule dan target group yang dideklarasikan sebagai dua directive sederhana: http.path dan http.healthcheck.


Cara lain yang menjadikan memulai dengan container di AWS menggunakan Copilot itu menyenangkan adalah Copilot menggunakan Dockerfile sebagai input. Copilot akan secara otomatis melakukan parsing file untuk menemukan instruksi seperti HEALTHCHECK atau EXPOSE dan secara otomatis mengisi nilai-nilai ini dalam manifes. Di waktu deployment, manifes tersebut akan diterjemahkan ke template AWS CloudFormation yang memberikan Anda transparansi penuh dari sumber daya yang sedang dibuat.

2. Membangun aplikasi modern secara default.

Aplikasi modern dapat terdiri dari satu atau lebih layanan, job, dan sumber daya pendukung seperti database. Copilot memastikan bahwa semua bagian aplikasi terhubung dengan aman dan sebaik mungkin.

Di dalam Copilot, aplikasi hanyalah namespace untuk kumpulan layanan yang terkait. Untuk mendapatkan arsitektur untuk aplikasi Anda, Copilot menyediakan integrasi mendalam antar layanan di dalam satu atau beberapa deployment environment.

Misalnya, beberapa layanan “Load Balanced Web” di dalam sebuah environment akan menggunakan Application Load Balancer yang sama tetapi akan memiliki path yang berbeda. Namespace untuk service discovery selalu dibentuk untuk memungkinkan komunikasi antar layanan yang private. Terakhir, Copilot akan melakukan injection untuk environment variable yang diperlukan sehingga kode Anda dapat memanfaatkan endpoints yang telah dibentuk oleh Copilot.


Dalam gambar di atas, layanan “vote-site” telah di-deploy di dua environment, yaitu “test” dan “prod-pdx.” Layanan ini dapat dijangkau di vote-site.$COPILOT_SERVICE_DISCOVERY_ENDPOINT melalui service discovery atau Anda dapat menjalankan request ke $COPILOT_LB_DBS dan request tersebut akan diteruskan dari load balancer.

Untuk mendapatkan sumber daya pendukung seperti tabel di Amazon DynamoDB, Anda dapat menjalankan copilot storage init. Copilot akan menambahkan permissions yang dibutuhkan ke dalam ECS TaskRole untuk memungkinkan aplikasi Anda untuk mengakses database dan melakukan injection environment variables agar kode layanan Anda dapat terhubung dengan tabel tersebut.

3. Deploy aplikasi secara berkesinambungan.

Meskipun AWS Copilot dapat digunakan untuk deploy perubahan aplikasi secara manual, kustomer dapat menggunakan Copilot untuk implementasi CI/CD dengan cara menyiapkan dan mengelola pipeline.

Aspek terakhir untuk memberikan layanan dengan praktik terbaik adalah membuat pipeline untuk Continuous Delivery (CD). Kami paham bahwa CD menghasilkan peningkatan kualitas perangkat lunak, oleh karena itu kami menambahkan fitur pipeline ke dalam Copilot.

Dengan Copilot, Anda dapat membuat beberapa environment deployment dengan menjalankan copilot env init. CLI akan meminta Anda untuk memilih named profile untuk akun dan AWS Region untuk enviroment Anda, untuk memungkinkan Anda melakukan deployment ke seluruh akun dan AWS Region. Copilot akan secara otomatis membentuk repositori Amazon ECR untuk setiap layanan dan Region environment untuk aplikasi Anda. Repositori terpisah per Region untuk setiap layanan menghilangkan biaya transfer data dan meminimalkan blast radius.

Setelah Anda memiliki environment, copilot pipeline init akan membuat pipeline dengan menggunakan layanan AWS CodePipeline untuk aplikasi Anda. Dari titik itu, Anda dapat melakukan commit and push perubahan Anda ke repositori Git upstream dan pipeline akan dimulai. Di dalam tahap “Build”, image container dibentuk dari Dockerfile yang ada di dalam repositori Anda dan di-push ke repositori Amazon ECR, untuk menjamin container image yang sama digunakan di seluruh environment.


Gambar di atas menunjukkan pipeline yang dibentuk oleh AWS Copilot di dalam AWS CodePipeline dengan 3 layanan: “vote-admin,” “vote-api,” dan “vote-site” yang sedang dilakukan deployment untuk dua environment: “test” dan “prod-pdx”.

4. Proses operasi adalah bagian dari alur kerja.

Pemodelan, provisioning, dan deployment aplikasi hanyalah bagian dari siklus hidup aplikasi untuk para developer. CLI harus mendukung alur kerja seputar troubleshooting dan debugging untuk membantu ketika terjadi masalah.

Untuk menutup siklus pada pengembangan aplikasi, Copilot dapat memantau kesehatan aplikasi Anda dan membantu Anda melakukan troubleshooting bila terjadi kesalahan. Copilot memiliki perintah copilot svc status dan copilot svc logs sebagai perintah operasional untuk melihat kesehatan layanan Anda dan logs aplikasi.

Apa selanjutnya?

Akan ada lebih banyak pola arsitektur ditambahkan ke dalam Copilot. Sejauh ini, yang paling seru adalah bagaimana kami dapat membuat integrasi ini lebih mudah. Mari kita ambil contoh pola untuk layanan asynchronous yang menggunakan message dari queue. Biasanya, ini mengharuskan kita untuk menentukan queue menggunakan Amazon Simple Queue Service (Amazon SQS) yang sudah subscribe ke sebuah topic dengan Amazon Simple Notification Service (Amazon SNS) dengan permission yang sesuai. Dengan Copilot, kami dapat mengubah pengalaman untuk para developer untuk melakukan subscribe dari layanan A terhadap events dari layanan B untuk topik tertentu dan semua infrastruktur dihasilkan dari Copilot.

Ini adalah titik awal dari perintah operasional di dalam AWS Copilot. Ada begitu banyak hal yang bisa dijelajahi terkait tracing, service mesh, pembuatan metrik, alarm, dan dasbor secara otomatis untuk layanan Anda. Kami ingin mendengar pendapat Anda tentang bagaimana kami dapat membantu Anda untuk melakukan debugging aplikasi menjadi lebih mudah.

Mari terlibat!

AWS Copilot sepenuhnya adalah open source! Anda dapat melihat repositori GitHub ini untuk berdiskusi bersama melalui Issues dan melakukan kontribusi melalui pull request. Anda dapat mempelajari lebih lanjut tentang cara menginstal dan memulai dengan Copilot dari dokumentasi kami.

Artikel ini diterjemahkan dari artikel dengan judul “AWS Copilot: an application-first CLI for containers on AWS**” yang ditulis oleh Efe Karakus, Senior Software Development Engineer, AWS.

Donnie Prakoso

Donnie Prakoso

Donnie Prakoso is a software engineer, self-proclaimed barista, and Principal Developer Advocate at AWS. With more than 17 years of experience in the technology industry, from telecommunications, banking to startups. He is now focusing on helping the developers to understand varieties of technology to transform their ideas into execution. He loves coffee and any discussion of any topics from microservices to AI / ML.