feat/haproxy #12

Merged
lanson merged 6 commits from feat/haproxy into main 2024-08-29 18:15:27 +00:00
40 changed files with 43 additions and 829 deletions
Showing only changes of commit dc096e497d - Show all commits

View File

@ -29,15 +29,13 @@ Perform control plane upgrades with rolling updates, ensuring that your services
## 🛠️ How to Get Started
1. Install the Collection:
1. Head to the [Quick-Start Guide](https://git.ednz.fr/ansible-collections/hashistack/wiki/02-quick-start)
```shell
ansible-galaxy collection install ednz_cloud.hashistack:==<version>
```
This should give you a good idea of how the collection works, and what it can do.
2. Head to the [Quick-Start Guide](https://git.ednz.fr/ansible-collections/hashistack/wiki/quick_start)
2. From there, you can follow the rest of the [Documentation](https://git.ednz.fr/ansible-collections/hashistack/wiki/01-introduction)
You'll get
This will allow you to customize your deployment to your exact needs !
## 🧑‍💻 Contributions & Feedback

BIN
assets/boundary_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/boundary_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/consul_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

BIN
assets/consul_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

BIN
assets/hashicorp_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

BIN
assets/nomad_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/nomad_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/packer_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/packer_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/terraform_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/vagrant_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

BIN
assets/vagrant_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/vault_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

BIN
assets/vault_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

BIN
assets/waypoint_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

BIN
assets/waypoint_white_500x500.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

1
docs/README.md Normal file
View File

@ -0,0 +1 @@
You can find the documentation for this project in the [Wiki](https://git.ednz.fr/ansible-collections/hashistack/wiki)

View File

@ -1,97 +0,0 @@
# Architecture Guide
Hashistack-Ansible allows you to deploy a number of architecture, wether you want to deploy a dev, testing, or production environment. These different architectures are described in this section.
## Dev deployment
If you only want to deploy a test environment, you can simply add a simgle host to each service that you want to deploy.
```ini
[haproxy_servers]
[vault_servers]
test01
[consul_servers]
test01
[nomad_servers]
test01
```
In this example, you will end end with each service running on a single host, with no clustering, and no redundancy. This setup *IS NOT RECOMMENDED** for anything but testing purposes, as it provides zero resiliency, and will break if anything goes down.
For this setup, the only requirement is for the target host to have a network interface that you can ssh into from the deployment host.
The architecture would like something like this:
```mermaid
graph LR;
client[Client] -->|http| server{
Vault Server
Consul Server
Nomad Server
};
```
## Testing/Preprod deployment
For testing, of pre-production deployments, running all services on the same nodes might be a good way to cut cost and/or save resources.
## Production deployment
For production use, it is recommended to separate concerns as much as possible. This means that consul, vault and nomad, as well as the haproxy services, should be on different nodes altogether. The **client-facing** and **cluster-facing** interfaces should also be separated.
Ideally, you would need:
- an odd number (3 to 5) of consul servers
- an odd number (3 to 5) of vault servers
- an odd number (3 to 5) of nomad servers
- multiple (2 to 3) haproxy servers
The **nomad**, **vault** and **consul** servers should have **two network interfaces**, and one of them should be reachable from the haproxy nodes.
The architecture for this infrastructure would look like:
```mermaid
graph TD
client[Client] -->|https :443| keepalived
keepalived[VIP] --> haproxy1[HAProxy] & haproxy2[HAProxy]
subgraph frontends
direction LR
haproxy1[HAProxy]
haproxy2[HAProxy]
end
haproxy1[HAProxy] & haproxy2[HAProxy] -->|http :8500| consul
subgraph consul
direction LR
consul1[Consul 01] <--> consul2[Consul 02] & consul3[Consul 03] & consul4[Consul 04] & consul5[Consul 05]
consul2[Consul 02] <--> consul3[Consul 03] & consul4[Consul 04] & consul5[Consul 05]
consul3[Consul 03] <--> consul4[Consul 04] & consul5[Consul 05]
consul4[Consul 04] <--> consul5[Consul 05]
end
haproxy1[HAProxy] & haproxy2[HAProxy] -->|http :8200| vault
subgraph vault
direction LR
vault1[Vault 01] <--> vault2[Vault 02]
vault2[Vault 02] <--> vault3[Vault 03]
vault3[Vault 03] <--> vault1[Vault 01]
end
vault -->|Service registration| consul
haproxy1[HAProxy] & haproxy2[HAProxy] -->|http :4646| nomad
subgraph nomad
direction LR
nomad1[Nomad 01] <--> nomad2[Nomad 02]
nomad2[Nomad 02] <--> nomad3[Nomad 03]
nomad3[Nomad 03] <--> nomad1[Nomad 01]
end
nomad -->|Service registration| consul
```
> **Note**: you can substract the haproxy part if using an external load-balancing solution, like AWS ALB,or any other LB technology, for connecting to your platform.

View File

@ -1,3 +0,0 @@
# Deploying a Consul cluster
This documentation explains each steps necessary to successfully deploy a Consul cluster using the ednz_cloud.hashistack ansible collection.

View File

@ -1 +0,0 @@
# Adding extra configuration options

View File

@ -1,103 +0,0 @@
# General documentation
## Configuration directory
### Main configuration directory
Hashistack Ansible uses a configuration directory to store all the configuration files and other artifacts.
This directory is defined with the variable `hashistack_configuration_directory`. By default, it will look at `{{ lookup('env', 'PWD') }}/etc/hashistack`, which equals `$(pwd)/etc/hashistack`.
Under this directory, you are expected to place the `globals.yml` file, with your configuration.
### Sub configuration directories
#### Group configuration directories
Additionally, subdirectories can be used to tailor the configuration further.
Each group within the `inventory` will look at a directory named after itself:
- nomad_servers group will look for `{{ hashistack_configuration_directory }}/nomad_servers`
- vault_servers group will look for `{{ hashistack_configuration_directory }}/vault_servers`
- consul_servers group will look for `{{ hashistack_configuration_directory }}/consul_servers`
Within each of these directories, you can place an additional `globals.yml file`, that will superseed the file at the root of the configuration directory.
- **Example**:
If `etc/hashistack/globals.yml` looks like:
```yaml
---
enable_vault: "no"
enable_consul: "no"
enable_nomad: "no"
```
And `etc/hashistack/nomad_servers/globals.yml` looks like:
```yaml
---
enable_nomad: "yes"
```
Servers in the `nomad_servers` group will end up with the following configuration:
```yaml
---
enable_vault: "no"
enable_consul: "no"
enable_nomad: "yes"
```
This approach lets you customize your deployment for your exact needs.
#### Host configuration directories
Additionally, within each `group configuration directory`, you can add `host configuration directory`, that will be named after the hosts defined in your `inventory`. These host directories can also be populated with a `globals.yml` file, that will superseed the `group` and `deployment` configuration files.
- **Example**
If `etc/hashistack/globals.yml` looks like:
```yaml
---
enable_vault: "no"
enable_consul: "no"
enable_nomad: "no"
api_interface: "eth0"
```
And `etc/hashistack/nomad_servers/globals.yml` looks like:
```yaml
---
enable_nomad: "yes"
api_interface: "eth1"
```
And `etc/hashistack/nomad_servers/nomad-master-01/globals.yml` looks like:
```yaml
api_interface: "eth0.vlan40"
```
Servers in the `nomad_servers` group will end up with the following configuration:
```yaml
---
enable_vault: "no"
enable_consul: "no"
enable_nomad: "yes"
api_interface: "eth1"
```
Except for host `nomad-master-01`, who will have the following:
```yaml
---
enable_vault: "no"
enable_consul: "no"
enable_nomad: "yes"
api_interface: "eth0.vlan40"
```

View File

@ -1,104 +0,0 @@
# Deploying HAProxy frontends
This documentation explains each steps necessary to successfully deploy HAProxy frontends for your deployment, using the ednz_cloud.hashistack ansible collection.
## Prerequisites
You should, before attempting any deployment, have read through the [Quick Start Guide](./quick_start.md). These steps are necessary in order to ensure smooth operations going forward.
## Variables
### Basics
First, in order to deploy the HAproxy frontends, you need to enable the deployment.
```yaml
enable_haproxy: "yes"
```
You can also configure the version of haproxy you would like to use. This has very little impact, and should most likely be left untouched to whatever the collection version is defaulting to (which is the version that it is tested against).
```yaml
haproxy_version: "2.8"
```
This version can either be `latest`, or any `X`, `X.Y`, `X.Y.Z` tag of the [haproxytech/haproxy-debian](https://hub.docker.com/r/haproxytech/haproxy-debian) docker image.
For production deployment, it is recommended to use the `X.Y.Z` syntax.
The `deployment_method` variable will define how to install vault on the nodes.
By default, it runs haproxy inside a docker container, but this can be changed to `host` to install haproxy from the package manager.
Note that not all versions of haproxy are available as a package on all supported distributions. Please refer to the documentation of [ednz_cloud.deploy_haproxy](https://github.com/ednz-cloud/deploy_haproxy) for details about supported versions when installing from the package manager.
```yaml
deployment_method: "docker"
```
### General settings
There aren't many settings that you can configure to deploy the HAProxy frontends. First you'll need to configure a Virtual IP, and pass it in the `globals.yml` configuration file.
```yaml
hashistack_external_vip_interface: "eth0"
hashistack_external_vip_addr: "192.168.121.100"
```
This is used to configure keepalived to automatically configure this VIP on one of the frontend, and handle failover.
You also need to configure the names that will resolve to your different applications (consul, nomad, vault). These names should resolve to your Virtual IP, and will be used to handle host-based routing on haproxy.
```yaml
consul_fqdn: consul.ednz.lab
vault_fqdn: vault.ednz.lab
nomad_fqdn: nomad.ednz.lab
```
With this configuration, querying `http://consul.ednz.lab` will give you the consul UI and API, through haproxy.
> Note: subpaths are not yet supported, so you cannot set the fqdn to `generic.domain.tld/consul`. This feature will be added in a future release.
### Enabling external TLS
To enable external TLS for your APIs and UIs, you will need to set the following variable.
```yaml
enable_tls_external: true
```
This will enable the https listener for haproxy and configure the http listener to be a https redirect only.
## Managing external TLS certificates
### Generating certificates with hashistack-ansible
If you don't care about having trusted certificates (e.g. for developement or testing purposes), you can generate some self-signed certificates for your applications using the `generate_certs.yml` playbook.
```bash
ansible-playbook -i multinode.ini ednz_cloud.hashistack.generate_certs.yml
```
This will generate self-signed certificates for each applications that has been enabled in your `globals.yml`, and for then respective fqdn (also configured in `globals.yml`).
These certificates are going to be placed in `etc/hashistack/certificates/external/`, and will be named after each fqdn. These files should be encrypted using something like ansible-vault, as they are sensitive.
### Managing your own TLS certificates
Similarly, you can manage your own TLS certificates, signed by your own CA. Your certificates should be placed in the `etc/hashistack/certificates/external/` directory, similar to the self-signed ones, and be named like:
`<your_fqdn>.pem` and `<your_fqdn>.pem.key`, for each application.
At the moment, setting all certificates in a single file is not supported, but will be added in a later release.
These certificates will be copied over to the `haproxy_servers` hosts, in `/var/lib/haproxy/certs/`.
### Managing certificates externally
In case you already have systems in place to deploy and renew your certificates, you can simply enable the options in `globals.yml` to not manage certificates directly in hashistack-ansible.
```yaml
external_tls_externally_managed_certs: true
```
Enabling this option will prevents the playbooks from trying to copy certificates over, but the HAProxy nodes will still expect them to be present. It is up to you to copy them over.

View File

@ -1,82 +0,0 @@
# Deploying a Nomad cluster
This documentation explains each steps necessary to successfully deploy a Nomad cluster using the ednz_cloud.hashistack ansible collection.
## Prerequisites
You should, before attempting any deployment, have read through the [Quick Start Guide](./quick_start.md). These steps are necessary in order to ensure smooth operations going forward.
## Variables
### Basics
First, in order to deploy a nomad cluster, you need to enable it.
```yaml
enable_nomad: "yes"
```
Selecting the nomad version to install is done with the `nomad_version` variable.
```yaml
nomad_version: latest
```
The vault version can either be `latest` or `X.Y.Z`.
For production deployment, it is recommended to use the `X.Y.Z` syntax.
### General settings
First, you can change some general settings for nomad, like the dc and region options.
```yaml
nomad_datacenter: dc1
nomad_region: global
```
### ACLs settings
By default, ACLs are enabled on nomad, and automatically bootstrapped.
You can change this by editing the `nomad_acl_configuration` variable:
```yaml
nomad_acl_configuration:
enabled: true
token_ttl: 30s
policy_ttl: 60s
role_ttl: 60s
```
### Consul integration settings
By default, if consul if also enabled, nomad will use it to register itself as a consul service and also use consul to automatically join the cluster.
```yaml
nomad_enable_consul_integration: "{{ enable_consul | bool }}"
nomad_consul_integration_configuration:
address: "127.0.0.1:{{ hashicorp_consul_configuration.ports.https if consul_enable_tls else hashicorp_consul_configuration.ports.http }}"
auto_advertise: true
ssl: "{{ consul_enable_tls | bool }}"
token: "{{ _credentials.consul.tokens.nomad.server.secret_id if nomad_enable_server else _credentials.consul.tokens.nomad.client.secret_id}}"
tags: []
```
Optionally, you can add tags to you nomad services, or disable the consul integration if you don't plan on using it.
### Vault integration settings
Vault integration for nomad is by default disabled, as it requires some vault configuration that is out of the scope of this collection.
You can, once you have deployed and configured vault (or if you are using an external vault not managed by the collection), enable the integration
```yaml
nomad_enable_vault_integration: false
nomad_vault_integration_configuration: {}
```
For configuration options, please refer to the [Official Documentation](https://developer.hashicorp.com/nomad/docs/configuration/vault)
### Drivers settings
### Internal TLS

View File

@ -1,154 +0,0 @@
# Quick Start Guide
This documentation will show you the preparation steps necessary to ensure that you environment is ready to deploy cluster(s).
## Prerequisites
### Recommended readings
Its beneficial to learn basics of both [Ansible](https://docs.ansible.com/) and [Docker](https://docs.docker.com/)(for docker deployments) before running Hashistack Ansible.
### Operating
The only supported operating systems currently are:
- Debian
- 11, Bullseye
- 12, Bookworm
- Ubuntu
- 20.04, Focal
- 22.04, Jammy
Other Debian-based distributions might work, but **are not tested**, and may break at any given update.
### Target Hosts
Target hosts are the hosts you are planning on deploying cluster(s) to.
These hosts must satisfy the following minimum requirements:
- Be reachable via ssh by the deployment node (the machine running the ansible playbooks), with a user that has the ability to escalate privileges.
- Be able to comunicate with each other, according to your cluster topology (vault hosts must all be able to reach each other, etc...)
- Be synced to a common time
- Have less than 10ms of latency to reach each other (raft consensus algorithm requirement)
- Be using systemd as their init system.
Ideally, hosts are recommended to satisfy the following recommendations:
- Have 2 network interfaces:
- One that is public facing for client-to-server traffic
- One that is not public facing for server-to-server and deployment-to-server communications
- Have a minimum of 8GB of memory (less will work, but the larger the scale, the higher the RAM requirements will be)
- Have a minimum of 40GB of free disk space
## Prepare the deployment host
1. Install the virtual environment dependencies.
```bash
sudo apt update
sudo apt install git python3-dev libffi-dev gcc libssl-dev python3-venv
```
2. Create a python virtual environment and activate it.
```bash
python3 -m venv /path/to/venv
source /path/to/venv/bin/activate
```
3. Ensure the latest version of pip is installed
```bash
pip install -U pip
```
4. Install [Ansible](http://www.ansible.com/). Hashistack-Ansible requires at least Ansible **7**(or ansible-core **2.15**)
```bash
pip install 'ansible-core>=2.15'
```
5. Create the directory structure. This is not required but **heavily** recommended.
```bash
mkdir -p etc/hashistack collections inventory roles
touch ansible.cfg
```
Your directory structure should look like this
```bash
.
├── ansible.cfg
├── collections
├── etc
│   └── hashistack
├── inventory
└── roles
```
6. Edit the `ansible.cfg` file with the minimum requirements.
```bash
[defaults]
roles_path = ./roles/
collections_path = ./collections/
inventory = ./inventory/
```
7. Install the `ednz_cloud.hashistack` ansible collection
```bash
ansible-galaxy collection install ednz_cloud.hashistack:==<version>
```
You should now have a directory under `./collections/ansible_collections/ednz_cloud/hashistack`
8. Install the other dependencies required by `ednz_cloud.hashistack`
```bash
ansible-galaxy install -r ./collections/ansible_collections/ednz_cloud/hashistack/roles/requirements.yml
```
This will install roles that are not packaged with the collection, but are still required in order to run the playbooks.
You should now have some roles inside `./roles/`.
9. Copy `inventory` file and `globals.yml `file locally
```bash
cp collections/ansible_collections/ednz_cloud/hashistack/playbooks/inventory/multinode.ini inventory/
```
```bash
cp collections/ansible_collections/ednz_cloud/hashistack/playbooks/group_vars/all/globals.yml etc/hashistack/globals.yml
```
## Generate Credentials
Before deploying your infrastructure with Hashistack-Ansible, you need to generate credentials that will be used to bootstrap the various clusters.
This can be done by running the `generate_credentials.yml` playbook.
```bash
ansible-playbook -i inventory/inventory.ini ednz_cloud.hashistack.generate_credentials.yml
```
This will create and populate `etc/hashistack/secrets/credentials.yml`
> [!WARNING]
> This file is VERY SENSITIVE, as it holds the root tokens and other credentials for consul and nomad clusters.
This does not generate vault credentials, as it is not possible to generate those in advance. These credentials will be generated, if you enable the vault deployment, during the bootstrap process of the vault cluster, and stored in `etc/hashistack/secrets/vault.yml`
> [!WARNING]
> It is HIGHLY recommended to encrypt these two files before enventually commiting them to source control. You can do so using tools like [ansible-vault](https://docs.ansible.com/ansible/latest/cli/ansible-vault.html) or [sops](https://github.com/getsops/sops).
## Running preflight checks and bootstrap playbooks
Before running the main deployment playbook, you might want to run the `bootstrap` and `preflight` playbooks, which do a number of checks to ensure all hosts are setup correctly for deployment.
```bash
ansible-playbook -i inventory/inventory.ini ednz_cloud.hashistack.bootstrap.yml
ansible-playbook -i inventory/inventory.ini ednz_cloud.hashistack.preflight.yml
```
These playbooks will run a number of checks, and installations, in order to ensure the target hosts, as well as your deployment environment are correctly setup in order to install all the components.

View File

@ -1,6 +0,0 @@
# TLS Guide
create certificate/ca directory
`ansible-playbook -i inventory/multinode.ini ednz_cloud.hashistack.generate_certs.yml`

View File

@ -1,107 +0,0 @@
# Deploying a Vault cluster
This documentation explains each steps necessary to successfully deploy a Vault cluster using the ednz_cloud.hashistack ansible collection.
## Prerequisites
You should, before attempting any deployment, have read through the [Quick Start Guide](./quick_start.md). These steps are necessary in order to ensure smooth operations going forward.
## Variables
### Basics
First, in order to deploy a Vault cluster, you need to enable it.
```yaml
enable_vault: "yes"
```
Selecting the vault version to install is done with the `vault_version` variable.
```yaml
vault_version: latest
```
The vault version can either be `latest` or `X.Y.Z`.
For production deployment, it is recommended to use the `X.Y.Z` syntax.
### General settings
First, you can change some general settings for vault.
```yaml
vault_cluster_name: vault
vault_enable_ui: true
vault_seal_configuration:
key_shares: 3
key_threshold: 2
```
### Storage settings
The storage configuration for vault can be edited as well. By default, vault will be configured to setup `raft` storage between all declared vault servers (in the `vault_servers` group).
```yaml
vault_storage_configuration:
raft:
path: "{{ hashicorp_vault_data_dir }}/data"
node_id: "{{ ansible_hostname }}"
retry_join: |
[
{% for host in groups['vault_servers'] %}
{
'leader_api_addr': 'http://{{ hostvars[host].api_interface_address }}:8200'
}{% if not loop.last %},{% endif %}
{% endfor %}
]
```
While this is the [recommended](https://developer.hashicorp.com/vault/docs/configuration/storage#integrated-storage-vs-external-storage) way to configure storage for vault, you can edit this variable to enable any storage you want. Refer to the [vault documentation](https://developer.hashicorp.com/vault/docs/configuration/storage) for compatibility and syntax details about this variable.
Example:
```yaml
# MySQL storage configuration
vault_storage_configuration:
mysql:
address: "10.1.10.10:3006"
username: "vault"
password: "vault"
database: "vault"
```
### Listener settings
#### TCP listeners
By default, TLS is **disabled** for vault. This goes against the Hashicorp recommendations on the matter, but there is no simple way to force the use of TLS (yet), without adding a lot of complexity to the deployment.
The listener configuration settings can be modified in `vault_listener_configuration` variable.
```yaml
vault_listener_configuration:
tcp:
address: "0.0.0.0:8200"
tls_disable: true
```
By default, vault will listen on all interfaces, on port 8200. you can change it by modifying the `tcp.address` property, and adding you own listener preferences.
#### Enabling TLS for Vault
In order to enable TLS for Vault, you simply need to set the `vault_enable_tls` variable to `true`.
At the moment, hashistack-Ansible does nothing to help you generate the certificates and renew them. All it does is look inside the `etc/hashistack/vault_servers/tls` directory on the deployment node, and copy the files to the destination hosts in `/etc/vault.d/config/tls`. The listener expect **2 files** by default, a `cert.pem`, and a `key.pem` file.
Please refer to the [vault documentation](https://developer.hashicorp.com/vault/docs/configuration/listener/tcp) for details bout enabling TLS on vault listeners.
In case you want to add more configuration to the vault listeners, you can add it to the `vault_extra_listener_configuration` variable, which by default is empty. This variable will be merge with the rest ofthe listener configuration variables, and takes precedence over all the others.
> **Waring**
> At the moment, hashistack-ansible does not support setting up multiple TCP listeners. Only one can be set.
### Plugins for Vault
To enable plugin support for Vault, you can set the `vault_enable_plugins` variable to true. This variable will add the necessary configuration options in the vault.json file to enable support. Once enabled, you can simply place your compiled plugin files into the `etc/hashistack/vault_servers/plugin` directory. They will be copied over to the `/etc/vault.d/config/plugin` directory on the target nodes.
Refer to the [vault documentation](https://developer.hashicorp.com/vault/docs/plugins/plugin-management) for details about enabling and using plugins.

View File

@ -21,7 +21,8 @@ issues: http://example.com/issue/tracker
# artifact. A pattern is matched from the relative path of the file or directory of the collection directory. This
# uses 'fnmatch' to match the files or directories. Some directories and files like 'galaxy.yml', '*.pyc', '*.retry',
# and '.git' are always filtered. Mutually exclusive with 'manifest'
build_ignore: []
build_ignore:
- assets/*
# A dict controlling use of manifest directives used in building the collection artifact. The key 'directives' is a
# list of MANIFEST.in style
# L(directives,https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands). The key

View File

@ -1,6 +1,6 @@
---
- name: Include certificate generation playbook
ansible.builtin.import_playbook: ednz_cloud.hashistack.generate_certs.yml
ansible.builtin.import_playbook: ednz_cloud.hashistack.certificates.yml
- name: Include bootstrap playbook
ansible.builtin.import_playbook: ednz_cloud.hashistack.bootstrap.yml

View File

@ -1,6 +1,6 @@
---
- name: Include certificate generation playbook
ansible.builtin.import_playbook: ednz_cloud.hashistack.generate_certs.yml
ansible.builtin.import_playbook: ednz_cloud.hashistack.certificates.yml
- name: Include bootstrap playbook
ansible.builtin.import_playbook: ednz_cloud.hashistack.bootstrap.yml

View File

@ -56,18 +56,3 @@
apply:
tags:
- nomad
# - fail:
# Haproxy nodes deployment
# - name: "Deploy Proxies"
# tags:
# - haproxy
# when:
# - enable_haproxy | bool
# block:
# - name: "Deploy Haproxy & Keepalived"
# ansible.builtin.import_tasks:
# file: tasks/haproxy/haproxy_deploy.yml
# when:
# - "'haproxy_servers' in group_names"

View File

@ -1,21 +0,0 @@
---
# hashistack generate certificates playbook
- name: "Generate certificates"
hosts: all, !deployment
strategy: linear
gather_facts: true
become: true
tasks:
- name: "Import variables"
ansible.builtin.include_role:
name: ednz_cloud.hashistack.hashistack
tags:
- always
- name: "Create Certificate Authority"
ansible.builtin.include_role:
name: ednz_cloud.hashistack.hashistack_ca
apply:
delegate_to: localhost
tags:
- always

View File

@ -1,85 +0,0 @@
---
# hashistack generate certificates playbook
- name: "Generate credentials"
hosts: deployment
strategy: linear
gather_facts: true
become: true
tasks:
- name: "Generate consul credentials"
block:
- name: "Generate consul gossip encryption key"
block:
- name: "Generate 24 random bytes and base64 encode"
ansible.builtin.shell:
cmd: |
set -o pipefail
dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64
executable: /bin/bash
changed_when: false
register: _consul_random_base64_string
- name: "Generate consul gossip encryption key"
ansible.builtin.set_fact:
_consul_gossip_encryption_key: "{{ _consul_random_base64_string.stdout }}"
- name: "Generate consul root credentials"
ansible.builtin.set_fact:
_consul_root_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Generate consul agents credentials"
ansible.builtin.set_fact:
_consul_agents_accessor: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
_consul_agents_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Generate consul vault credentials"
ansible.builtin.set_fact:
_consul_vault_accessor: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
_consul_vault_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Generate consul nomad server credentials"
ansible.builtin.set_fact:
_consul_nomad_server_accessor: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
_consul_nomad_server_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Generate consul nomad client credentials"
ansible.builtin.set_fact:
_consul_nomad_client_accessor: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
_consul_nomad_client_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Generate nomad credentials"
block:
- name: "Generate nomad gossip encryption key"
block:
- name: "Generate 24 random bytes and base64 encode"
ansible.builtin.shell:
cmd: |
set -o pipefail
dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64
executable: /bin/bash
changed_when: false
register: _nomad_random_base64_string
- name: "Generate nomad gossip encryption key"
ansible.builtin.set_fact:
_nomad_gossip_encryption_key: "{{ _nomad_random_base64_string.stdout }}"
- name: "Generate nomad root credentials"
ansible.builtin.set_fact:
_nomad_root_token: "{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_letters','digits']) | to_uuid }}"
- name: "Ensure secrets directory is created"
ansible.builtin.file:
path: "{{ hashistack_sub_configuration_directories['secrets'] }}"
state: directory
owner: "{{ lookup('env', 'USER') }}"
group: "{{ lookup('env', 'USER') }}"
mode: '0755'
- name: "Write credentials file"
ansible.builtin.template:
src: templates/credentials.yml.j2
dest: "{{ hashistack_sub_configuration_directories['secrets'] }}/{{ hashistack_configuration_credentials_vars_file }}"
owner: "{{ lookup('env', 'USER') }}"
group: "{{ lookup('env', 'USER') }}"
mode: '0644'

View File

@ -42,3 +42,36 @@ consul_required_ports: [8300, 8301, 8302, 8500, 8501, 8502, 8503, 8600]
nomad_required_ports: [4646, 4647, 4648]
target: all, !deployment
#############################################################
# consul -- DO NOT TWEAK UNLESS YOU KNOW WHAT YOU ARE DOING #
#############################################################
consul_init_server: "{{ (inventory_hostname == groups['consul_servers'][0]) | bool }}"
consul_api_addr: "{{ consul_api_scheme }}://{{ api_interface_address }}:{{ consul_api_port[consul_api_scheme] }}"
consul_api_scheme: "{{ 'https' if consul_enable_tls else 'http' }}"
consul_api_port:
http: 8500
https: 8501
consul_grpc_port:
http: 8502
https: 8503
############################################################
# nomad -- DO NOT TWEAK UNLESS YOU KNOW WHAT YOU ARE DOING #
############################################################
nomad_init_server: "{{ (inventory_hostname == groups['nomad_servers'][0]) | bool }}"
nomad_api_addr: "{{ nomad_api_scheme }}://{{ api_interface_address }}:{{ nomad_api_port[nomad_api_scheme] }}"
nomad_api_scheme: "{{ 'https' if nomad_enable_tls else 'http' }}"
nomad_api_port:
http: "{{ nomad_address_configuration.ports.http }}"
https: "{{ nomad_address_configuration.ports.http }}"
############################################################
# vault -- DO NOT TWEAK UNLESS YOU KNOW WHAT YOU ARE DOING #
############################################################
vault_init_server: "{{ (inventory_hostname == groups['vault_servers'][0]) | bool }}"

View File

@ -1,19 +1,4 @@
---
consul_init_server: "{{ (inventory_hostname == groups['consul_servers'][0]) | bool }}"
#####################
# consul api config #
#####################
consul_api_addr: "{{ consul_api_scheme }}://{{ api_interface_address }}:{{ consul_api_port[consul_api_scheme] }}"
consul_api_scheme: "{{ 'https' if consul_enable_tls else 'http' }}"
consul_api_port:
http: 8500
https: 8501
consul_grpc_port:
http: 8502
https: 8503
##########
# Consul #
##########

View File

@ -3,7 +3,6 @@
# General options #
###################
enable_ingress: "yes"
enable_vault: "yes"
enable_consul: "yes"
enable_nomad: "yes"
@ -16,11 +15,6 @@ consul_fqdn: consul.ednz.lab
vault_fqdn: vault.ednz.lab
nomad_fqdn: nomad.ednz.lab
# hashistack_external_vip_interface: "eth0"
# hashistack_external_vip_addr: "192.168.121.100"
# hashistack_internal_vip_interface: "{{ hashistack_external_vip_interface }}"
# hashistack_internal_vip_addr: "{{ hashistack_external_vip_addr }}"
api_interface: "eth0"
api_interface_address: "{{ ansible_facts[api_interface]['ipv4']['address'] }}"

View File

@ -1,16 +1,4 @@
---
nomad_init_server: "{{ (inventory_hostname == groups['nomad_servers'][0]) | bool }}"
####################
# nomad api config #
####################
nomad_api_addr: "{{ nomad_api_scheme }}://{{ api_interface_address }}:{{ nomad_api_port[nomad_api_scheme] }}"
nomad_api_scheme: "{{ 'https' if nomad_enable_tls else 'http' }}"
nomad_api_port:
http: "{{ nomad_address_configuration.ports.http }}"
https: "{{ nomad_address_configuration.ports.http }}"
#########
# Nomad #
#########
@ -101,7 +89,7 @@ nomad_client_configuration:
bridge_network_subnet: "172.26.64.0/20"
node_pool: >-
{{
'ingress' if 'haproxy_servers' in group_names else
'ingress' if 'nomad_ingress' in group_names else
'controller' if 'nomad_servers' in group_names else
omit
}}

View File

@ -1,6 +1,4 @@
---
vault_init_server: "{{ (inventory_hostname == groups['vault_servers'][0]) | bool }}"
#########
# Vault #
#########

View File

@ -1,7 +1,3 @@
[haproxy_servers]
haproxy01
haproxy02
[vault_servers]
vault01
vault02
@ -25,7 +21,6 @@ nomad-client03
[consul_agents]
[consul_agents:children]
haproxy_servers
vault_servers
nomad_servers
nomad_clients
@ -45,7 +40,6 @@ nomad_clients
vault_servers
[common:children]
haproxy_servers
vault_servers
consul_servers
nomad_servers