infrastructure management solution

[jacobdotcosta]

Hi!

📢 I've created PR #250 as the first version of how the Ansible Container solution for performing infrastructure operations would look like. The following functionalitites should already be working:

• vm creation
• vm removal
• k8s installation

Even though the solution is working, it still seems a bit difficult to setup on each machine as everyone needs to have:

• it's own passwordstore setup
  • pass repository
  • gpg keys configured
  • gpg keys shared with the container
• ssh keys in place and shared with the container

To make things worst the commands executed aren't as friendly as one could hope.

To create a VM.

podman run --privileged -it --rm \
         -v ${HOME}/.gnupg:/opt/volumes/gnupg:Z \
         -v ${HOME}/.ssh:/root/.ssh:Z  \
         --env-file ${HOME}/.k8s-infra-container.env \
         --env-file container/samples/vm_create.env \
          -e CLOUD_PROVIDER=openstack \
         -e PASS_GPG_KEY_PASSPHRASE=${PASS_GPG_KEY_PASSPHRASE} \
         -e VM_NAME=${VM_NAME} \
         -e VM_FLAVOR="ci.m5.large" \
         -e VM_IMAGE="CentOS-8-x86_64-GenericCloud-released-latest" \
         -e K8S_VERSION="121" \
         localhost/k8s-infra-ansible

To install k8s.

podman run --privileged -it --rm \ 
      -v ${HOME}/.gnupg:/opt/volumes/gnupg:Z \ 
      -v ${HOME}/.ssh:/root/.ssh:Z \ 
      --env-file ${HOME}/.k8s-infra-container.env \ 
      -e PASS_GPG_KEY_PASSPHRASE=${PASS_GPG_KEY_PASSPHRASE} \ 
      --env-file container/samples/k8s_install.env \ 
      -e VM_NAME=myvm \ 
      localhost/k8s-infra-ansible

Besides this, some differences might come up depending on the client setup either using docker or podman.

The alternative could be having this solution deployed as a service which might reduce or even remove the complexity of the local installation. Check #250 (comment) . The interactions with this solution could be either using a CLI or a web interface.

Could you share your thoughts on this? Do you think the current solution usable? What do you think?

Thank you.

[cmoulliard]

Let's discuss first, the option which is to have a container image. If we follow down that road, I have some questions about it

1. Purpose of the --env-file
   Why do we have to set an --env-file pointing to vm_create.env instead of passing some arguments to the container's run ?
   Example docker run create-vm arg1=val1 arg2=val2?
   Why do we have to set --env-file ${HOME}/.k8s-infra-container.env ?

2. Password store and GPG key
   Why dont you simply end of the creation/deletion process issue a command to the user to explain what they should do to update the password store locally. In this case, it is not needed to mount the .ssh and/or .gnugpg folders like to pass the PASS_GPG_KEY_PASSPHRASE env var - correct ?

@jacobdotcosta

[jacobdotcosta]

Regarding 1., the env files are not mandatory. They exist only to simplify the parameters to pass to the container inside 1 file, like a template.

Regarding 2., our ansible roles have been developed with the passwordstore integration in mind. The ansible inventory is stored inside the passwordstore so we can all share it. When a VM is created, for instance, besides storing the host information and ansible access data, SSH keys are also stored on it (which are later automatically added as ssh keys in the ${HOME}/.ssh folder). To decouple we'd need to start with changing the way we store and share the inventory.

I'll check possibilities for changing the inventory location.

[cmoulliard]

with the passwordstore integration in mind

Ok. Can we imagine that the container's image is configured with a dummy user having a gpg key and been able to access the git repository ?

[jacobdotcosta]

with the passwordstore integration in mind

Ok. Can we imagine that the container's image is configured with a dummy user having a gpg key and been able to access the git repository ?

I think we can, but I'm not sure it will reduce the complexity of the container itself. We might not have to share the GPG store but we'll have to provide one to the container. The container will then have the GPG key which IMO is a security risk.