Menjalankan Stack di VPC - AWS OpsWorks
Dasar-dasar VPCBuat VPC untuk Stacks Stack AWS OpsWorks

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menjalankan Stack di VPC

penting

AWS OpsWorks Stacks Layanan ini mencapai akhir masa pakai pada 26 Mei 2024 dan telah dinonaktifkan untuk pelanggan baru dan yang sudah ada. Kami sangat menyarankan pelanggan untuk memindahkan beban kerja mereka ke solusi lain sesegera mungkin. Jika Anda memiliki pertanyaan tentang migrasi, hubungi AWS Dukungan Tim di AWS re:Post atau melalui AWS Dukungan Premium.

Anda dapat mengontrol akses pengguna ke instance stack dengan membuatnya di virtual private cloud (VPC). Misalnya, Anda mungkin tidak ingin pengguna memiliki akses langsung ke server aplikasi atau database stack Anda dan sebagai gantinya mengharuskan semua lalu lintas publik disalurkan melalui penyeimbang beban elastis.

Prosedur dasar untuk menjalankan tumpukan di VPC adalah:

  1. Buat VPC yang dikonfigurasi dengan tepat, dengan menggunakan konsol atau API VPC Amazon, atau templat. AWS CloudFormation

  2. Tentukan ID VPC saat Anda membuat tumpukan.

  3. Luncurkan instance tumpukan di subnet yang sesuai.

Berikut ini secara singkat menjelaskan bagaimana VPCs bekerja di AWS OpsWorks Stacks.

penting

Jika Anda menggunakan fitur VPC Endpoint, ketahuilah bahwa setiap instance dalam tumpukan harus dapat menyelesaikan tindakan berikut dari Amazon Simple Storage Service (Amazon S3):

  • Instal agen instance.

  • Instal aset, seperti Ruby.

  • Unggah log jalankan Chef.

  • Ambil perintah tumpukan.

Untuk mengaktifkan tindakan ini, Anda harus memastikan bahwa instance tumpukan memiliki akses ke bucket berikut yang cocok dengan wilayah tumpukan. Jika tidak, tindakan sebelumnya akan gagal.

Untuk Chef 12 Linux dan Chef 12.2 Windows, bucket adalah sebagai berikut.

Ember Agen Ember Aset Ember Log Ember DNA

  • opsworks-instance-agent-sa-timur-1

  • opsworks-instance-agent-ap-selatan-1

  • opsworks-instance-agent-ap-timur laut-1

  • opsworks-instance-agent-ap-timur laut-2

  • opsworks-instance-agent-ap-tenggara 1

  • opsworks-instance-agent-ap-tenggara 2

  • opsworks-instance-agent-ca-pusat-1

  • opsworks-instance-agent-eu-pusat-1

  • opsworks-instance-agent-eu-barat-1

  • opsworks-instance-agent-eu-barat-2

  • opsworks-instance-agent-eu-barat-3

  • opsworks-instance-agent-us-timur-1

  • opsworks-instance-agent-us-timur-2

  • opsworks-instance-agent-us-barat-1

  • opsworks-instance-agent-us-barat-2

  • opsworks-instance-assets-us-timur-2

  • opsworks-instance-assets-us-timur-1

  • opsworks-instance-assets-ap-selatan-1

  • opsworks-instance-assets-ap-timur laut-1

  • opsworks-instance-assets-ap-timur laut-2

  • opsworks-instance-assets-ap-tenggara 1

  • opsworks-instance-assets-ap-tenggara 2

  • opsworks-instance-assets-ca-pusat-1

  • opsworks-instance-assets-eu-pusat-1

  • opsworks-instance-assets-eu-barat-1

  • opsworks-instance-assets-eu-barat-2

  • opsworks-instance-assets-eu-barat-3

  • opsworks-instance-assets-sa-timur-1

  • opsworks-instance-assets-us-barat-1

  • opsworks-instance-assets-us-barat-2

  • opsworks-us-east-2-log

  • opsworks-us-east-1-log

  • opsworks-ap-south-1-log

  • opsworks-ap-northeast-1-log

  • opsworks-ap-northeast-2-log

  • opsworks-ap-southeast-1-log

  • opsworks-ap-southeast-2-log

  • opsworks-ca-central-1-log

  • opsworks-eu-central-1-log

  • opsworks-eu-west-1-log

  • opsworks-eu-west-2-log

  • opsworks-eu-west-3-log

  • opsworks-sa-east-1-log

  • opsworks-us-west-1-log

  • opsworks-us-west-2-log

  • opsworks-us-east-2-dna

  • opsworks-us-east-1-dna

  • opsworks-ap-south-1-dna

  • opsworks-ap-northeast-1-dna

  • opsworks-ap-northeast-2-dna

  • opsworks-ap-southeast-1-dna

  • opsworks-ap-southeast-2-dna

  • opsworks-ca-central-1-dna

  • opsworks-eu-central-1-dna

  • opsworks-eu-west-1-dna

  • opsworks-eu-west-2-dna

  • opsworks-eu-west-3-dna

  • opsworks-sa-east-1-dna

  • opsworks-us-west-1-dna

  • opsworks-us-west-2-dna

Untuk Chef 11.10 dan versi sebelumnya untuk Linux, bucket adalah sebagai berikut. Tumpukan Chef 11.4 tidak didukung di titik akhir regional di luar Wilayah AS Timur (Virginia N.).

Ember Agen Ember Aset Ember Log Ember DNA

  • opsworks-instance-agent-us-timur-2

  • opsworks-instance-agent-us-timur-1

  • opsworks-instance-agent-ap-selatan-1

  • opsworks-instance-agent-ap-timur laut-1

  • opsworks-instance-agent-ap-timur laut-2

  • opsworks-instance-agent-ap-tenggara 1

  • opsworks-instance-agent-ap-tenggara 2

  • opsworks-instance-agent-ca-pusat-1

  • opsworks-instance-agent-eu-pusat-1

  • opsworks-instance-agent-eu-barat-1

  • opsworks-instance-agent-eu-barat-2

  • opsworks-instance-agent-eu-barat-3

  • opsworks-instance-agent-us-timur-1

  • opsworks-instance-agent-us-barat-1

  • opsworks-instance-agent-us-barat-2

  • opsworks-instance-assets-us-timur-2

  • opsworks-instance-assets-us-timur-1

  • opsworks-instance-assets-ap-selatan-1

  • opsworks-instance-assets-ap-timur laut-1

  • opsworks-instance-assets-ap-timur laut-2

  • opsworks-instance-assets-ap-tenggara 1

  • opsworks-instance-assets-ap-tenggara 2

  • opsworks-instance-assets-ca-pusat-1

  • opsworks-instance-assets-eu-pusat-1

  • opsworks-instance-assets-eu-barat-1

  • opsworks-instance-assets-eu-barat-2

  • opsworks-instance-assets-eu-barat-3

  • opsworks-instance-assets-sa-timur-1

  • opsworks-instance-assets-us-barat-1

  • opsworks-instance-assets-us-barat-2

  • prod_stage-log

  • prod_tahap-dna

Untuk informasi lebih lanjut, lihat VPC endpoint.

catatan

Agar AWS OpsWorks Stacks dapat terhubung ke titik akhir VPC yang Anda aktifkan, Anda juga harus mengonfigurasi perutean untuk NAT atau IP publik, karena agen Stacks masih memerlukan AWS OpsWorks akses ke titik akhir publik.

Dasar-dasar VPC

Untuk pembahasan mendetail tentang VPCs, lihat Amazon Virtual Private Cloud. Secara singkat, VPC terdiri dari satu atau lebih subnet, yang masing-masing berisi satu atau lebih instance. Setiap subnet memiliki tabel routing terkait yang mengarahkan lalu lintas keluar berdasarkan alamat IP tujuannya.

  • Instans dalam VPC dapat berkomunikasi satu sama lain secara default, terlepas dari subnet mereka. Namun, perubahan pada daftar kontrol akses jaringan (ACLs), kebijakan grup keamanan, atau menggunakan alamat IP statis dapat merusak komunikasi ini.

  • Subnet yang instansinya dapat berkomunikasi dengan Internet disebut sebagai subnet publik.

  • Subnet yang instansnya hanya dapat berkomunikasi dengan instans lain di VPC dan tidak dapat berkomunikasi langsung dengan Internet disebut sebagai subnet pribadi.

AWS OpsWorks Tumpukan memerlukan VPC untuk dikonfigurasi sehingga setiap instance dalam tumpukan, termasuk instance dalam subnet pribadi, memiliki akses ke titik akhir berikut:

  • Salah satu titik akhir layanan AWS OpsWorks Stacks yang tercantum di bagian “Dukungan Wilayah”. Memulai dengan AWS OpsWorks Stacks

  • Salah satu titik akhir layanan contoh berikut, digunakan oleh agen AWS OpsWorks Stacks. Agen berjalan pada instance pelanggan terkelola untuk bertukar data dengan layanan.

    • opsworks-instance-service.us-east-2.amazonaws.com

    • opsworks-instance-service.us-east-1.amazonaws.com

    • opsworks-instance-service.us-west-1.amazonaws.com

    • opsworks-instance-service.us-west-2.amazonaws.com

    • opsworks-instance-service.ap-selatan-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-2.amazonaws.com

    • opsworks-instance-service.ap-tenggara 1.amazonaws.com

    • opsworks-instance-service.ap-tenggara 2.amazonaws.com

    • opsworks-instance-service.ca-central-1.amazonaws.com

    • opsworks-instance-service.eu-central-1.amazonaws.com

    • opsworks-instance-service.eu-west-1.amazonaws.com

    • opsworks-instance-service.eu-west-2.amazonaws.com

    • opsworks-instance-service.eu-west-3.amazonaws.com

  • Amazon S3

  • Repositori paket apa pun yang bergantung pada sistem operasi Anda, seperti repositori Amazon Linux atau Ubuntu Linux.

  • Aplikasi dan repositori buku masak khusus Anda.

Ada berbagai cara untuk mengkonfigurasi VPC untuk menyediakan konektivitas ini. Berikut ini adalah contoh sederhana bagaimana Anda dapat mengonfigurasi VPC untuk tumpukan server aplikasi AWS OpsWorks Stacks.

VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.

VPC ini memiliki beberapa komponen:

Subnet

VPC memiliki dua subnet, satu publik dan satu pribadi.

  • Subnet publik berisi penyeimbang beban dan perangkat terjemahan alamat jaringan (NAT), yang dapat berkomunikasi dengan alamat eksternal dan dengan instance di subnet pribadi.

  • Subnet pribadi berisi server aplikasi, yang dapat berkomunikasi dengan NAT dan penyeimbang beban di subnet publik tetapi tidak dapat berkomunikasi langsung dengan alamat eksternal.

Gerbang internet

Gateway Internet memungkinkan instance dengan alamat IP publik, seperti penyeimbang beban, untuk berkomunikasi dengan alamat di luar VPC.

Penyeimbang beban

Penyeimbang beban Elastic Load Balancing mengambil lalu lintas masuk dari pengguna, mendistribusikannya ke server aplikasi di subnet pribadi, dan mengembalikan respons kepada pengguna.

NAT

Perangkat (NAT) menyediakan server aplikasi dengan akses Internet terbatas, yang biasanya digunakan untuk tujuan seperti mengunduh pembaruan perangkat lunak dari repositori eksternal. Semua instance AWS OpsWorks Stacks harus dapat berkomunikasi dengan AWS OpsWorks Stacks dan dengan repositori Linux yang sesuai. Salah satu cara untuk menangani masalah ini adalah dengan menempatkan perangkat NAT dengan alamat IP Elastis terkait di subnet publik. Anda kemudian dapat merutekan lalu lintas keluar dari instance di subnet pribadi melalui NAT.

catatan

Sebuah instance NAT tunggal menciptakan satu titik kegagalan dalam lalu lintas keluar subnet pribadi Anda. Anda dapat meningkatkan keandalan dengan mengonfigurasi VPC dengan sepasang instance NAT yang mengambil alih satu sama lain jika salah satu gagal. Untuk informasi selengkapnya, lihat Ketersediaan Tinggi untuk Instans NAT VPC Amazon. Anda juga dapat menggunakan gateway NAT. Untuk informasi selengkapnya, lihat NAT di Panduan Pengguna Amazon VPC.

Konfigurasi VPC yang optimal tergantung pada AWS OpsWorks tumpukan Stacks Anda. Berikut ini adalah beberapa contoh kapan Anda mungkin menggunakan konfigurasi VPC tertentu. Untuk contoh skenario VPC lainnya, lihat Skenario untuk Menggunakan Amazon VPC.

Bekerja dengan satu instance di subnet publik

Jika Anda memiliki tumpukan instans tunggal tanpa sumber daya pribadi terkait—seperti instans Amazon RDS yang seharusnya tidak dapat diakses publik — Anda dapat membuat VPC dengan satu subnet publik dan menempatkan instance di subnet tersebut. Jika Anda tidak menggunakan VPC default, Anda harus memiliki lapisan instance yang menetapkan alamat IP Elastis ke instance. Untuk informasi selengkapnya, lihat OpsWorks Dasar-dasar Lapisan.

Bekerja dengan sumber daya pribadi

Jika Anda memiliki sumber daya yang seharusnya tidak dapat diakses publik, Anda dapat membuat VPC dengan satu subnet publik dan satu subnet pribadi. Misalnya, dalam lingkungan penskalaan otomatis load-balanced, Anda dapat menempatkan semua EC2 instans Amazon di subnet pribadi dan penyeimbang beban di subnet publik. Dengan begitu EC2 instans Amazon tidak dapat diakses langsung dari Internet; semua lalu lintas yang masuk harus diarahkan melalui penyeimbang beban.

Subnet pribadi mengisolasi instance dari akses pengguna EC2 langsung Amazon, tetapi mereka masih harus mengirim permintaan keluar ke AWS dan repositori paket Linux yang sesuai. Untuk mengizinkan permintaan tersebut, Anda dapat, misalnya, menggunakan perangkat terjemahan alamat jaringan (NAT) dengan alamat IP Elastisnya sendiri dan kemudian merutekan lalu lintas keluar instans melalui NAT. Anda dapat menempatkan NAT di subnet publik yang sama dengan penyeimbang beban, seperti yang ditunjukkan pada contoh sebelumnya.

  • Jika Anda menggunakan database back-end seperti instans Amazon RDS, Anda dapat menempatkan instance tersebut di subnet pribadi. Untuk instans Amazon RDS, Anda harus menentukan setidaknya dua subnet berbeda di Availability Zone yang berbeda.

  • Jika Anda memerlukan akses langsung ke instance di subnet pribadi—misalnya, Anda ingin menggunakan SSH untuk masuk ke instance—Anda dapat menempatkan host bastion di subnet publik yang meminta proxy dari Internet.

Memperluas jaringan Anda sendiri ke AWS

Jika Anda ingin memperluas jaringan Anda sendiri ke cloud dan juga langsung mengakses Internet dari VPC Anda, Anda dapat membuat gateway VPN. Untuk informasi selengkapnya, lihat Skenario 3: VPC dengan Subnet Publik dan Pribadi serta Akses VPN Perangkat Keras.

Buat VPC untuk Stacks Stack AWS OpsWorks

Bagian ini menunjukkan cara membuat VPC untuk tumpukan AWS OpsWorks Stacks dengan menggunakan contoh template AWS. CloudFormation Anda dapat mengunduh template di OpsWorksVPCtemplatesfile.zip. Untuk informasi lebih lanjut tentang cara membuat VPC secara manual seperti yang dibahas dalam topik ini, lihat Skenario 2: VPC dengan Subnet Publik dan Pribadi. Untuk detail tentang cara mengkonfigurasi tabel routing, grup keamanan, dan sebagainya, lihat contoh template.

catatan

Secara default, AWS OpsWorks Stacks menampilkan nama subnet dengan menggabungkan rentang CIDR dan Availability Zone mereka, seperti. 10.0.0.1/24 - us-east-1b Untuk membuat nama lebih mudah dibaca, buat tag untuk setiap subnet dengan Key set ke Name dan Value diatur ke nama subnet. AWS OpsWorks Tumpukan kemudian menambahkan nama subnet ke nama default. Misalnya, subnet pribadi dalam contoh berikut memiliki tag dengan Nama disetel kePrivate, yang OpsWorks menampilkan sebagai10.0.0.1/24 us-east - 1b - Private.

Anda dapat meluncurkan template VPC menggunakan AWS CloudFormation konsol hanya dengan beberapa langkah. Prosedur berikut menggunakan contoh template untuk membuat VPC di Wilayah AS Timur (Virginia N.). Untuk petunjuk tentang cara menggunakan template untuk membuat VPC di wilayah lain, lihat catatan yang mengikuti prosedur.

Untuk membuat VPC

  1. Buka AWS CloudFormation konsol, pilih wilayah US East (Virginia N.), dan pilih Create Stack.

  2. Pada halaman Select Template, pilih Upload a template. Jelajahi OpsWorksinVPC.template file yang Anda unduh di OpsWorksVPCtemplatesfile.zip. Pilih Lanjutkan.

    CloudFormation Pilih halaman Template

    Anda juga dapat meluncurkan tumpukan ini dengan membuka AWS CloudFormation Sample Templates, menemukan template AWS OpsWorks VPC Stacks, dan memilih Launch Stack.

  3. Pada halaman Tentukan Parameter, terima nilai default dan pilih Lanjutkan.

  4. Pada halaman Tambahkan Tag, buat tag dengan Kunci diatur ke Name dan Nilai diatur ke nama VPC. Tag ini akan memudahkan untuk mengidentifikasi VPC Anda saat Anda membuat AWS OpsWorks tumpukan Stacks.

  5. Pilih Lanjutkan dan kemudian Tutup untuk meluncurkan tumpukan.

Catatan: Anda dapat membuat VPC di wilayah lain dengan menggunakan salah satu pendekatan berikut.

Contoh template mencakup output yang menyediakan VPC, subnet, dan IDs penyeimbang beban yang Anda perlukan untuk membuat tumpukan Stacks. AWS OpsWorks Anda dapat melihatnya dengan memilih tab Output di bagian bawah jendela AWS CloudFormation konsol.

Stack outputs table showing VPC, subnet, and load balancer IDs for an OpsWorks-in-VPC stack.