[ English | Indonesia | Deutsch | English (United Kingdom) | русский | español ]

Menginstal dengan konektivitas terbatas

Banyak buku pedoman dan peran di OpenStack-Ansible mengambil dependensi dari Internet publik secara default. Contoh konfigurasi mengasumsikan bahwa deployer menyediakan koneksi Internet berkualitas baik melalui router pada 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

Saat menjalankan OpenStack-Ansible di lingkungan jaringan yang memblokir konektivitas internet, kami menyarankan serangkaian praktik dan konfigurasi yang ditimpa untuk digunakan oleh deployers.

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 mencerminkan indeks paket PyPi yang digunakan oleh pip. Deployer dapat memilih untuk secara aktif mencerminkan seluruh repositori PyPi hulu, tetapi ini mungkin memerlukan sejumlah besar penyimpanan. Atau, proxy pip caching dapat digunakan untuk menyimpan salinan lokal hanya dari paket-paket yang diperlukan.

Untuk mengkonfigurasi penyebaran menggunakan indeks alternatif, buat file /etc/pip.conf dengan konten berikut dan pastikan bahwa itu berada di 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 pembuatan roda (wheel builds), Lihathttps://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, konfigurasikan penyebaran untuk menyalin file-file ini dari host ke dalam image 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.

Upstream Ubuntu repositories to mirror for Ubuntu 22.04 LTS:

  • jammy

  • jammy-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 builds LXC images using debootstrap or dnf depending on the distribution. In order to override the package repository you might need to adjust some variables, like lxc_apt_mirror or completely override build command with lxc_hosts_container_build_command Consult the openstack-ansible-lxc_hosts role for details on configuration overrides for this scenario.

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.

Deployers can configure the script to source Ansible from an alternate Git repository by setting the environment variable ANSIBLE_GIT_REPO. Also, during initial bootstrap you might need to define a custom URL for upper-constraints file that is part of openstack/requirements repository, using the TOX_CONSTRAINTS_FILE environment variable.

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.

Host target dan penyebaran dapat dikonfigurasikan untuk mencapai 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

Selain 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 dari penyebaran OpenStack harus langsung dan tidak melalui proxy. Variabel lingkungan no_proxy digunakan untuk menentukan host yang harus dijangkau langsung tanpa melalui proxy. Ini sering adalah host di jaringan manajemen.

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

1. 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.

2. 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:

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

2. 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.

3. 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.

4. 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 hosts/containers dalam penyebaran mencapai ukuran tertentu, panjang no_proxy akan melebihi 1024 karakter di mana pada saat itu wajib menggunakan pengaturan proxy sementara yang hanya memerlukan sebagian dari alamat IP jaringan manajemen untuk hadir dalam no_proxy pada waktu penempatan.

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

Proxying TLS traffic often interferes with the clients ability to perform successful validation of the certificate chain. Various configuration variables exist within the OpenStack-Ansible playbooks and roles that allow a deployer to ignore these validation failures. Disable certificate chain validation on a case by case basis and only after encountering failures that are known to only be caused by the proxy server(s).