In the new Ansible Container readme, there is this use case:
Many people use Docker for development environments only but then use Ansible playbooks to push out to staging or production. This allows you to use the same playbooks and roles in your Docker dev environment as in your production environments.
This seems very exciting, but I am not sure how will this be being achieved. Let’s say one uses Docker Composer to orchestrate containers. When you deploy to a “dockerless” VPS (let’s say Debian) all you have there is systemd. Does this mean that AnsibleContainer would know how to configure systemd on a 'dockerless" system, and use docker compose on a (local) dockered laptop?
Is this already available?
In the new Ansible Container readme, there is this use case:
Many people use Docker for development environments only but then use
Ansible playbooks to push out to staging or production. This allows you to
use the same playbooks and roles in your Docker dev environment as in your
production environments.
This seems very exciting, but I am not sure how will this be being achieved.
Let's say one uses Docker Composer to orchestrate containers. When you
deploy to a "dockerless" VPS (let's say Debian) all you have there is
systemd. Does this mean that AnsibleContainer would know how to configure
systemd on a 'dockerless" system, and use docker compose on a (local)
dockered laptop?
Is this already available?
The assumption we're making presently to get bootstrapped is that
Docker is the local target for build/run, and that Kubernetes is the
remote target for push/shipit. Other use cases may be possible in the
future, but this is the one we're aiming for first.
--g
Thanks Greg, maybe you want to improve the message there there.
…And maybe targeting systemd for service orchestration is something that can be done down the road