|
|
429202 |
# Common Operations to initialize a node/service in CentOS infra
|
|
|
429202 |
|
|
|
429202 |
Once the server (bare-metal, Virtual Machine - internal or EC2 instance- ) is deployed, we just need to add it to ansible inventory (probably already done already during `deploy` step so complete with the following information)
|
|
|
429202 |
|
|
|
429202 |
Requirements:
|
|
|
429202 |
|
|
|
429202 |
* Machine is reachable
|
|
|
429202 |
* You have initial credentials (either already injected ssh key and sudo right or just other equivalent credentials)
|
|
|
429202 |
* Access to required Ansible inventory
|
|
|
429202 |
|
|
|
429202 |
## Adding node
|
|
|
429202 |
|
|
|
429202 |
You first need to add the node into DNS (either internally or externally) so please have a look at the dedicated [DNS section](/infra/dns), and that means kicking the `role-bind.yml` or `role-unbound.yml` playbooks based on the need, and after having pushed the change to git.
|
|
|
429202 |
|
|
|
429202 |
Once the node is available, we need *once* to initialize the node to confirm access and ssh host key/fingerprint and then sign it with our SSH CA.
|
|
|
429202 |
|
|
|
429202 |
Let's start by first ensuring that we can log onto a node (in our example a EC2 instance):
|
|
|
429202 |
|
|
|
429202 |
```
|
|
|
429202 |
ssh centos@artwork-1.dev.centos.org uptime
|
|
|
429202 |
The authenticity of host 'artwork-1.dev.centos.org (<no hostip for proxy command>)' can't be established.
|
|
|
429202 |
ECDSA key fingerprint is SHA256:TFnZOT68OAkUQdTm1kCwoPxEN8d/4v/kqinsPcFD/04.
|
|
|
429202 |
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
|
|
|
429202 |
Warning: Permanently added 'artwork-1.dev.centos.org' (ECDSA) to the list of known hosts.
|
|
|
429202 |
09:41:48 up 7 min, 0 users, load average: 0.00, 0.06, 0.04
|
|
|
429202 |
|
|
|
429202 |
```
|
|
|
429202 |
|
|
|
09ef13 |
!!! tip
|
|
|
09ef13 |
it's also possible to *not* do the ssh host key checking, but not adviced, by using `ANSIBLE_HOST_KEY_CHECKING=False` env variable in front of the first playbook execution in the next steps. As said, it's possible and should *eventually* only be used for .dev. or .stg. environment, and on just provisioned instances (non public) like Virtual Machines
|
|
|
09ef13 |
|
|
|
09ef13 |
|
|
|
429202 |
Now we can proceed with next steps.
|
|
|
429202 |
Let's add the node in the correct Ansible inventory (like for example `CentOS-CI` or `CentOS-prod` or `CentOS-staging`, etc.
|
|
|
429202 |
|
|
|
429202 |
We first need to ensure that usual `sysadmins` will be granted first the correct rights and we just need to add the node in ansible inventory first.
|
|
|
429202 |
If you already know which roles you want to directly apply feel free to add into correct `[group_name]` in the inventory or just add it to `[unclassified]` first.
|
|
|
429202 |
When done, we can just play manually (only once) some playbooks and from there machine will be automatically reconfigured when role/inventory is updated (see the Ansible section about this)
|
|
|
429202 |
|
|
|
429202 |
```
|
|
|
429202 |
fqdn="artwork-1.dev.centos.org"
|
|
|
429202 |
ansible-playbook playbooks/adhoc-grant-access.yml -u centos -l ${fqdn} # or add -k to ask for password if needed to inject ssh keys
|
|
|
429202 |
```
|
|
|
429202 |
|
|
|
429202 |
Now that `sysadmins` have their keys injected (including yours), you can initialize the node , but it will create a temporary file that you can then copy into inventory for some gathered facts, so you can use `--extras-vars` just for this specific call
|
|
|
429202 |
|
|
|
429202 |
```
|
|
|
429202 |
out_dir="/home/arrfab/ansible/out"
|
|
|
429202 |
test -d ${out_dir} || mkdir -p ${out_dir}
|
|
|
429202 |
ansible-playbook playbooks/adhoc-init-node.yml -l ${fqdn} --extra-vars "out_dir=${out_dir}"
|
|
|
429202 |
cat ${out_dir}/${fqdn} >> inventory/host_vars/${fqdn}
|
|
|
429202 |
```
|
|
|
429202 |
|
|
|
429202 |
The `adhoc-init-node.yml` will do the following :
|
|
|
429202 |
|
|
|
429202 |
* (optional) retrieve the public IP and allow incoming connections from that new ip for some infra services restricted by iptables
|
|
|
429202 |
* retrieve ssh host keys, sign these and push the signed
|
|
|
429202 |
* retrieve locally some facts that can be used later for basic host_vars template
|
|
|
429202 |
* play the `baseline` role (common for *all* nodes but with different settings, based on inventory
|
|
|
429202 |
* (optional): play other roles that are tied to ansible inventory group membership (if you added the host already in some specific groups)
|
|
|
429202 |
|
|
|
429202 |
If you configured correctl
|
|
|
429202 |
|
|
|
429202 |
Now that machine is in ansible inventory, you can always add new role, based on group memberships, change settings through `group_vars` or `host_vars`, etc, so Ansible BAU
|
|
|
429202 |
|
|
|
4985a1 |
!!! note
|
|
|
4985a1 |
For sponsored nodes, ensure that you define a root password that is unique and set it. Don't forget to reflect it (normally not needed anymore) in `ansible/inventory/host_vars/<host>` with `root_password` (all git-crypted and/or ansible-vault crypted depending on the inventory). You can use something like `pwgen` tool or even just `openssl rand -base64 24` (as an example)
|