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)
Requirements:
You first need to add the node into DNS (either internally or externally) so please have a look at the dedicated DNS section, 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.
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.
Let's start by first ensuring that we can log onto a node (in our example a EC2 instance):
ssh centos@artwork-1.dev.centos.org uptime The authenticity of host 'artwork-1.dev.centos.org (<no hostip for proxy command>)' can't be established. ECDSA key fingerprint is SHA256:TFnZOT68OAkUQdTm1kCwoPxEN8d/4v/kqinsPcFD/04. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'artwork-1.dev.centos.org' (ECDSA) to the list of known hosts. 09:41:48 up 7 min, 0 users, load average: 0.00, 0.06, 0.04
Tip
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
Now we can proceed with next steps.
Let's add the node in the correct Ansible inventory (like for example CentOS-CI
or CentOS-prod
or CentOS-staging
, etc.
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.
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.
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)
fqdn="artwork-1.dev.centos.org" ansible-playbook playbooks/adhoc-grant-access.yml -u centos -l ${fqdn} # or add -k to ask for password if needed to inject ssh keys
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
out_dir="/home/arrfab/ansible/out" test -d ${out_dir} || mkdir -p ${out_dir} ansible-playbook playbooks/adhoc-init-node.yml -l ${fqdn} --extra-vars "out_dir=${out_dir}" cat ${out_dir}/${fqdn} >> inventory/host_vars/${fqdn}
The adhoc-init-node.yml
will do the following :
baseline
role (common for all nodes but with different settings, based on inventoryrhel_host_use_cdn
variable/boolean in ansible)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
Note
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)