[ English | 한국어 (대한민국) | Deutsch | русский | français | Indonesia | English (United Kingdom) ]

Menginstal dengan konektivitas terbatas

Banyak playbook dan role di OpenStack-Ansible mengambil dependensi dari Internet publik secara default. Contoh konfigurasi mengasumsikan bahwa deployer menyediakan konektivitas Internet berkualitas baik melalui router di jaringan manajemen OpenStack.

Deployment dapat menemui konektivitas eksternal terbatas karena sejumlah alasan:

  • Konektivitas eksternal bandwidth rendah atau tidak dapat diandalkan

  • Aturan firewall yang memblokir konektivitas eksternal

  • Konektivitas eksternal diperlukan melalui proxy HTTP atau SOCKS

  • Keputusan arsitektur oleh penggelar untuk mengisolasi jaringan OpenStack

  • Lingkungan keamanan tinggi di mana tidak ada konektivitas eksternal diizinkan

Kami merekomendasikan serangkaian praktik dan konfigurasi penimpaan yang dapat digunakan oleh deployer ketika menjalankan OpenStack-Ansible di lingkungan jaringan yang memblokir konektivitas Internet.

Opsi di bawah ini tidak eksklusif satu sama lain dan dapat digabungkan jika diinginkan.

Contoh ketergantungan internet

  • Paket python

  • Paket khusus distribusi

  • Image kontainer LXC

  • Repositori kode sumber

  • Kunci GPG untuk validasi paket

Praktek A: sumber daya internet mirror secara lokal

Anda dapat memilih untuk mengoperasikan dan memelihara mirror dependensi OpenStack-Ansible dan OpenStack. Mirror sering kali memberikan banyak mitigasi risiko dengan mengurangi ketergantungan pada sumber daya dan sistem di luar kendali langsung Anda. Mirror juga dapat memberikan stabilitas, kinerja, dan keamanan yang lebih besar.

Repositori paket Python

Banyak paket yang digunakan untuk menjalankan OpenStack diinstal menggunakan pip. Kami menyarankan untuk melakukan mirroring indeks paket PyPi yang digunakan oleh pip. Penyebar dapat memilih untuk secara aktif mencerminkan (mirror) seluruh repositori PyPi hulu tetapi ini mungkin memerlukan sejumlah besar penyimpanan. Atau proksi pip caching dapat digunakan untuk menyimpan salinan lokal hanya dari paket yang diperlukan.

Untuk mengonfigurasi build menggunakan indeks alternatif, buat file /etc/pip.conf dengan konten berikut dan pastikan bahwa itu ditempatkan pada semua host di lingkungan.

[global]
index-url = http://pip.example.org/simple

Selain itu perlu untuk mengkonfigurasi easy_install untuk menggunakan indeks alternatif. easy_install digunakan sebagai ganti pip untuk menginstal apa pun yang terdaftar di bawah setup_requires di setup.py selama wheel builds. Lihat https://pip.pypa.io/en/latest/reference/pip_install/#controlling-setup-requires

Untuk mengonfigurasi easy_install agar menggunakan indeks alternatif, buat file /root/.pydistutils.cfg dengan konten berikut.

[easy_install]
index_url = https://pip.example.org/simple

Kemudian, di /etc/openstack_deploy/user_variables.yml, informasikan penyebaran yang dibutuhkan untuk menyalin file-file ini dari host ke dalam gambar cache kontainer.

# Copy these files from the host into the containers
lxc_container_cache_files_from_host:
  - /etc/pip.conf
  - /root/.pydistutils.cfg

Paket khusus distribusi

Banyak paket perangkat lunak yang diinstal pada host Ubuntu menggunakan paket .deb. Mekanisme pengemasan serupa ada untuk distribusi Linux lainnya. Kami menyarankan untuk mencerminkan (mirroring) repositori yang meng-host paket-paket ini.

Repositori Ubuntu upstream untuk mirror untuk Ubuntu 18.04 LTS:

  • bionic

  • bionic-updates

OpenStack-Ansible membutuhkan beberapa repositori lain untuk menginstal komponen tertentu seperti Galera dan Ceph.

Contoh repositori ke mirror (host target Ubuntu):

Daftar ini sengaja tidak lengkap dan setara akan diperlukan untuk distribusi Linux lainnya. Konsultasikan playbook OpenStack-Ansible dan dokumentasi role untuk repositori lebih lanjut dan variabel yang dapat digunakan untuk mengganti lokasi repositori.

Image kontainer LXC

OpenStack-Ansible bergantung pada image LXC buatan komunitas saat membuat container untuk layanan OpenStack. Deployer dapat memilih untuk membuat, memelihara, dan meng-host image kontainer mereka sendiri. Konsultasikan role openstack-ansible-lxc_container_create untuk detail konfigurasi override untuk skenario ini.

Repositori kode sumber

OpenStack-Ansible mengandalkan Ansible Galaxy untuk mengunduh role Ansible saat bootstrapping a deployment host. Penyebar mungkin ingin mencerminkan dependensi yang diunduh oleh skrip bootstrap-ansible.sh.

Deployer dapat mengkonfigurasi skrip ke sumber Ansible dari repositori Git alternatif dengan mengatur variabel lingkungan ANSIBLE_GIT_REPO.

Deployer dapat mengonfigurasi skrip ke sumber dependensi role Ansible dari lokasi alternatif dengan memberikan file persyaratan role khusus dan menentukan jalur ke file tersebut menggunakan variabel lingkungan ANSIBLE_ROLE_FILE.

Praktek B: Akses proxy ke sumber daya internet

Beberapa jaringan tidak memiliki akses terarah ke Internet, atau memerlukan lalu lintas tertentu untuk menggunakan gateway khusus aplikasi seperti server proxy HTTP atau SOCKS.

Konfigurasi dapat diterapkan ke host target dan penyebaran untuk menjangkau sumber daya internet publik melalui server proxy HTTP atau SOCKS. OpenStack-Ansible dapat digunakan untuk mengonfigurasi host target untuk menggunakan server proxy. OpenStack-Ansible tidak menyediakan otomatisasi untuk membuat server proxy.

Deployment host awal berada di luar ruang lingkup OpenStack-Ansible dan deployer harus memastikan set minimum konfigurasi proxy sudah ada, khususnya untuk manajer paket sistem.

konfigurasi proxy apt-get

Lihat Setting up apt-get to use a http-proxy

Konfigurasi proxy lainnya

Lebih jauh ke konfigurasi dasar ini, ada klien jaringan lain pada host target yang dapat dikonfigurasi untuk terhubung melalui proxy. Sebagai contoh:

  • Sebagian besar modul jaringan Python

  • curl

  • wget

  • openstack

Alat-alat ini dan pustaka-pustaka yang mendasarinya digunakan oleh Ansible sendiri dan playbook OpenStack-Ansible, sehingga harus ada konfigurasi proxy yang ada agar playbook dapat mengakses sumber daya eksternal dengan sukses.

Biasanya alat ini membaca variabel lingkungan yang berisi pengaturan server proxy. Variabel lingkungan ini dapat dikonfigurasi dalam /etc/environment jika diperlukan.

Penting untuk dicatat bahwa server proxy hanya boleh digunakan untuk mengakses sumber daya eksternal, dan komunikasi antara komponen internal penyebaran OpenStack harus langsung, tanpa melalui proxy. Variabel lingkungan no_proxy digunakan untuk menentukan host yang harus dijangkau secara langsung tanpa melalui proxy. Ini sering terjadi adalah host di jaringan manajemen.

OpenStack-Ansible menyediakan dua mekanisme berbeda untuk mengonfigurasi pengaturan server proxy:

#. The default configuration file suggests setting a persistent proxy configuration on all target hosts and defines a persistent no_proxy environment variable which lists all hosts/containers' management addresses as well as the load balancer internal/external addresses.

#. An alternative method applies proxy configuration in a transient manner during the execution of Ansible playbooks and defines a minimum set of management network IP addresses for no_proxy that are required for the playbooks to succeed. These proxy settings do not persist after an Ansible playbook run and the completed deployment does not require them in order to be functional.

Penyebar harus memutuskan pendekatan mana yang lebih cocok untuk host target, dengan mempertimbangkan panduan berikut:

#. Persistent proxy configuration is a standard practice and network clients on the target hosts will be able to access external resources after deployment.

#. The deployer must ensure that a persistent proxy configuration has complete coverage of all OpenStack management network host/containers' IP addresses in the no_proxy environment variable. It is necessary to use a list of IP addresses, CIDR notation is not valid for no_proxy.

#. Transient proxy configuration guarantees that proxy environment variables will not persist, ensuring direct communication between services on the OpenStack management network after deployment. Target host network clients such as wget will not be able to access external resources after deployment.

#. The maximum length of no_proxy should not exceed 1024 characters due to a fixed size buffer in the pam_env PAM module. Longer environment variables will be truncated during deployment operations and this will lead to unpredictable errors during or after deployment.

Setelah jumlah host/container dalam penyebaran mencapai ukuran tertentu, panjang no_proxy akan melebihi 1024 karakter. Maka wajib untuk menggunakan pengaturan proxy sementara yang hanya memerlukan subset dari alamat IP jaringan manajemen untuk muncul di no_proxy pada waktu penyebaran.

Rujuk ke global_environment_variables: dan deployment_environment_variables: dalam contoh user_variables.yml untuk detail konfigurasi variabel lingkungan proxy yang persisten dan sementara.

Konfigurasi proxy host deployment untuk bootstrapping Ansible

Konfigurasikan skrip bootstrap-ansible.sh yang digunakan untuk menginstal dependensi role Ansible dan Ansible pada host deployment untuk menggunakan proxy dengan mengatur variabel lingkungan HTTPS_PROXY atau HTTP_PROXY.

Catatan

Kami menyarankan Anda mengatur variabel /etc/environment Anda dengan pengaturan proxy sebelum meluncurkan skrip atau playbook apa saja untuk menghindari kegagalan.

Untuk lingkungan yang lebih besar atau kompleks, host deployment khusus (dedicated) memungkinkan konfigurasi proxy yang paling cocok untuk diterapkan pada host deployment maupun host target.

Pertimbangan saat mem-proxy lalu lintas TLS

Proxy traffic TLS seringkali mengganggu kemampuan klien untuk melakukan validasi rantai sertifikat secara sukses. Berbagai variabel konfigurasi ada di dalam playbook dan role OpenStack-Ansible yang memungkinkan deployer untuk mengabaikan kegagalan validasi ini. Temukan contoh konfigurasi /etc/openstack_deploy/user_variables.yml di bawah:

pip_validate_certs: false
galera_package_download_validate_certs: false

Daftar di atas sengaja tidak lengkap. Variabel tambahan mungkin ada dalam proyek dan akan dinamai menggunakan pola * _validate_certs. Nonaktifkan validasi rantai sertifikat berdasarkan kasus per kasus dan hanya setelah mengalami kegagalan yang diketahui hanya disebabkan oleh server proxy.