Hi Jeffrey,
Although I saw the Ansible Container repo, I wasn't that excited about it at the moment. It still feels complicated when compared to how Chef describes a container. However, it is still promising. On the reasons I did not choose to use it either is that Automated builds only handle Dockerfiles. I'd rather run a script in a statement to ensure it is one layer. and inside this script use Ansible to orchestrate when necessary. Anyways, I will have a better look at your code later... although I had one question after a quick glance, "did Kolla drop support for Fedora" ? regards, Gerard On Wed, Jun 29, 2016 at 8:50 PM, Jeffrey Zhang <[email protected]> wrote: > Recently, Ansible release 2.1 version with lots of new feature. One of the > interesting feature > is the management for docker. > > Redhat also announced the Ansible Container project[0][1], which can build > docker images by using > Ansible Playbooks. No more write the ugly Dockerfile script. I think this > will be more graceful. > > Here the explanation that why not use Dockerfile from ansible-container > readme file. > > A Dockerfile is not much more than a script with hand-crafted shell > commands. We're well past the > point where we should be managing build processes with manually maintained > series of shell scripts. > That's why we wrote Ansible in the first place, and this is just as > applicable to containers. > > Ansible Container permits orchestration even during the build process, > whereas docker build does > not. For example, in a Django project, your VCS may contain a bunch of > sources for static assets > that need to be compiled and then collected. With Ansible Container, you can > compile the static > assets in your Django container and then collect them into your static file > serving container. > > 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. > > Ansible Container does all of this without installing SSH, leaving Ansible > artifacts on your > built images, or having excess layers to the union filesystem. > > I also pushed a PS to implement almost the same thing for Kolla[3]. There > many benefit for this. > > 1. more easy to understand. The original base/Dockerfile is too long, mixed > with different base image logical > and different install type. Whereas in the new implement, it is more > clearly. it is split into multi > YAML file. > 2. easy to extend. We can reuse the role concept for the Ansible. For > example, when you want to extend > the neutron-server container. You can write your own roles, like > neutron-server-lbaas role, and just > add this to the neutron-server playbooks. In this way, we can implement > the customize issue. ( this will > implement later.) > 3. It is also possible to change the exist data. For example, i want to > change the repo url to a internal > ones. > The user can provide a ansible variables file, which hold the new repo url > and overwrite the > exist one. > > This PS is in POC stage. Post this mail to gather any advise and better > ideas. > > [0] https://github.com/ansible/ansible-container > [1] > https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/ > [2] https://review.openstack.org/334208 > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
