[ English | Indonesia | русский ]
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.
In order to configure the deployment to use an alternative index, you can define a variable pointing to your simple index:
openstack_pypi_url: http://pip.example.org/simple
It will be used as a fallback URL for the repo_server, when wheels are
being build. In production environment, this should be enough, as all other
hosts and containers should be fetching packages from the repo_server
container.
In case of deploying third-party services that rely on custom pip.conf
for requirements installation, you need to manually provision a pip.conf
file on LXC hosts and instruct OpenStack-Ansible to pass the config file
to related LXC containers. For that, you can set in
/etc/openstack_deploy/group_vars/${GROUP_NAME}.yml (where GROUP_NAME is
a group where arbitrary software belongs to), following variable:
# Copy these files from the host into the containers
lxc_container_cache_files_from_host:
- /etc/pip.conf
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 24.04 LTS:
noble
noble-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¶
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).