In support of run, and execution of artifacts produced by deploy, Ansible Container will rely on a set Ansible modules for k8s.
Initial modules
To support existing shipit functionality, the initial set of modules needs to include the following:
k8s_common
k8s_service
k8s_route (manage OpenShift route objects)
k8s_deployment
k8s_pvc (persistent volume claim)
What we have now is two set of modules, one for k8s and one for OpenShift, and they are part of the Ansible Container code base. The new modules must be part of the Ansible code base, and ideally, we should have a single set of modules that supports both platforms. There are of course differences between the platforms that we'll have to work around. For example, the route object is unique to OpenShift. It's used to expose a service externally, where k8s can expose a service directly. There are other difference as well, however, getting to a single set of modules is doable. And once achieved, the existing modules will be removed from Ansible Container.
The current modules" wrap the command line tool for each platform. It would be more desirable, if the modules communicated with the API. It would prevent us from having to install the CLI tools in the conductor, and users would likely prefer to not be required to install the client tools within their CI/CD infrastructure.
There is an emerging Python client that works with k8s, and I'm told will be contributed to by OpenShift, so it should eventually work with both platforms. In the meantime, there is a Red Hat library that may suffice in the interim.
Authentication
There are a number of different ways to authenticate with the API, including using encrypted secrets found in a config file, and initially Ansible Container is only going to support use of a config file:
Ansible Container's k8s engine will provide a CLI option for mounting /home/user/.kube or a custom path to an existing config file.
It will be up to the user to create a config file outside of Ansible Container.
The initial goal is to create modules that support Ansible Container. However, the modules need to support the broader Ansible community, and other use cases outside of Ansible Container, and therefore should eventually support the other authentication mechanisms.
In support of
run
, and execution of artifacts produced bydeploy
, Ansible Container will rely on a set Ansible modules for k8s.Initial modules
To support existing
shipit
functionality, the initial set of modules needs to include the following:What we have now is two set of modules, one for k8s and one for OpenShift, and they are part of the Ansible Container code base. The new modules must be part of the Ansible code base, and ideally, we should have a single set of modules that supports both platforms. There are of course differences between the platforms that we'll have to work around. For example, the
route
object is unique to OpenShift. It's used to expose a service externally, where k8s can expose a service directly. There are other difference as well, however, getting to a single set of modules is doable. And once achieved, the existing modules will be removed from Ansible Container.The current modules" wrap the command line tool for each platform. It would be more desirable, if the modules communicated with the API. It would prevent us from having to install the CLI tools in the conductor, and users would likely prefer to not be required to install the client tools within their CI/CD infrastructure.
There is an emerging Python client that works with k8s, and I'm told will be contributed to by OpenShift, so it should eventually work with both platforms. In the meantime, there is a Red Hat library that may suffice in the interim.
Authentication
There are a number of different ways to authenticate with the API, including using encrypted secrets found in a config file, and initially Ansible Container is only going to support use of a config file:
/home/user/.kube
or a custom path to an existing config file.The initial goal is to create modules that support Ansible Container. However, the modules need to support the broader Ansible community, and other use cases outside of Ansible Container, and therefore should eventually support the other authentication mechanisms.