openstack/openstack-ansible
Code Issues Proposed changes
18464e47f1
openstack-ansible/deploy-guide/source/app-limited-connectivity.rst
Jimmy McCrory 9cd42929c3 Support cidr_networks in L3 network environments 
In some environments, a single container, storage, or tunnel network may
not be applicable to every host. Each configured provider_network would
need to be limited to a particular subset of hosts and the host var keys
within the inventory for container_address, storage_address, and
tunnel_address will need to be maintained since they're specifically
required by various playbooks.

Add two new options for configuring provider_networks, 'reference_group'
and 'address_prefix'.

'reference_group' for providing a group name that any host must
be a member of, in addition to any of the groups listed in
'group_binds', for the network to be applied.

'address_prefix' for overriding the name of the key created for each IP
address allocated by a cidr_network. By default, this key is named
'cidr_network'_address, where 'cidr_network' is the given 'ip_from_q'
option for a provider network.

Closes-Bug: 1650356

Change-Id: Ia7f3119f0affc4fb6be97ca788ca3b46096b82a8
2017-07-31 22:14:25 +00:00

5.9 KiB
Raw Blame History

Appendix G: Installing with limited connectivity

Many playbooks and roles in OpenStack-Ansible retrieve dependencies from the public Internet by default. Many deployers block direct outbound connectivity to the Internet when implementing network security measures. We recommend a set of practices and configuration overrides deployers can use when running OpenStack-Ansible in network environments that block Internet connectivity.

The options below are not mutually exclusive and may be combined if desired.

Example internet dependencies

  • Software packages
  • LXC container images
  • Source code repositories
  • GPG keys for package validation

Practice A: Mirror internet resources locally

You may choose to operate and maintain mirrors of OpenStack-Ansible and OpenStack dependencies. Mirrors often provide a great deal of risk mitigation by reducing dependencies on resources and systems outside of your direct control. Mirrors can also provide greater stability, performance and security.

Software package repositories

Many packages used to run OpenStack are installed using pip. We advise mirroring the PyPi package index used by pip.

Many software packages are installed on the target hosts using .deb packages. We advise mirroring the repositories that host these packages.

Ubuntu repositories to mirror:

  • xenial
  • xenial-updates

Galera-related repositories to mirror:

These lists are intentionally not exhaustive. Consult the OpenStack-Ansible playbooks and role documentation for further repositories and the variables that may be used to override the repository location.

LXC container images

OpenStack-Ansible relies upon community built LXC images when building containers for OpenStack services. Deployers may choose to create, maintain, and host their own container images. Consult the openstack-ansible-lxc_container_create role for details on configuration overrides for this scenario.

Source code repositories

OpenStack-Ansible relies upon Ansible Galaxy to download Ansible roles when bootstrapping a deployment host. Deployers may wish to mirror the dependencies that are downloaded by the bootstrap-ansible.sh script.

Deployers can configure the script to source Ansible from an alternate Git repository by setting the environment variable ANSIBLE_GIT_REPO.

Deployers can configure the script to source Ansible role dependencies from alternate locations by providing a custom role requirements file and specifying the path to that file using the environment variable ANSIBLE_ROLE_FILE.

Practice B: Proxy access to internet resources

Configure target and deployment hosts to reach public internet resources via HTTP or SOCKS proxy server(s). OpenStack-Ansible may be used to configure target hosts to use the proxy server(s). OpenStack-Ansible does not provide automation for creating the proxy server(s).

Note

We recommend you set your /etc/environment variables with proxy settings before launching any scripts or playbooks to avoid failure.

Basic proxy configuration

The following configuration configures most network clients on the target hosts to connect via the specified proxy. For example, these settings affect:

  • Most Python network modules
  • curl
  • wget
  • openstack

Use the no_proxy environment variable to specify hosts that you cannot reach through the proxy. These often are the hosts in the management network. In the example below, no_proxy is set to localhost only, but the default configuration file suggests using variables to list all the hosts/containers' management addresses as well as the load balancer internal/external addresses.

Configuration changes are made in /etc/openstack_deploy/user_variables.yml.

# Used to populate /etc/environment
global_environment_variables:
   HTTP_PROXY: "http://proxy.example.com:3128"
   HTTPS_PROXY: "http://proxy.example.com:3128"
   NO_PROXY: "localhost,127.0.0.1"
   http_proxy: "http://proxy.example.com:3128"
   https_proxy: "http://proxy.example.com:3128"
   no_proxy: "localhost,127.0.0.1"

apt-get proxy configuration

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

Deployment host proxy configuration for bootstrapping Ansible

Configure the bootstrap-ansible.sh script used to install Ansible and Ansible role dependencies on the deployment host to use a proxy by setting the environment variables HTTPS_PROXY or HTTP_PROXY.

Considerations when proxying TLS traffic

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. Find an example /etc/openstack_deploy/user_variables.yml configuration below:

pip_validate_certs: false
galera_package_download_validate_certs: false

The list above is intentionally not exhaustive. Additional variables may exist within the project and will be named using the *_validate_certs pattern. 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).