<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 5:04 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there all-ye-operators,<br>
<br>
I am investigating how to help move godaddy from rpms to a container-like solution (virtualenvs, lxc, or docker...) and a set of questions that comes up is the following (and I would think that some folks on this mailing list may have some useful insight into the answers):<br>
<br>
* Have you done the transition?<br></blockquote><div>We've done the transition to containers using both RPM's as well as source code. We started out with just putting the RPM's into the container. We then moved to building the containers using the source code. There has been change in direction a bit that is requiring us to go back to RPM's which was a simple flip over from an RPM. </div><div><br></div><div>The biggest thing we had to think about was the configuration files. We wanted them to be as easy and clean as possible. We didn't want to keep creating tons of container images for all the different environments. At the end of the day, we realized that we could use ETCD to allow us to use environment variables to make configuration changes very easy. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* How did the transition go?<br></blockquote><div>It was very easy for us to move between RPM's on the host to containers. We started off with one project and worked through that and proceeded on to the next. We were easily able to mix and match between RPMs on the host and new containers. Our automation proved to be very useful to making things easier (obviously). </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Was/is kolla used or looked into? or something custom?<br></blockquote><div>We started down this process way before kolla was out there and running, so it would take a lot for us to move over to kolla as we have a pretty detailed deployment setup. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* How long did it take to do the transition from a package based solution (with say puppet/chef being used to deploy these packages)?<br></blockquote><div><br></div><div>It took a week or two honestly. It is a lot easier than you think. Just take your current configuration file, and put it inside the container and run it and see what happens. That was the easiest way to get started and see how they act within your environment. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Follow-up being how big was the team to do this?<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* What was the roll-out strategy to achieve the final container solution?<br></blockquote><div><br></div><div>We use ansible along with docker-compose to do all our file deployments. We use it to talk with haproxy to take the service out of rotation, wait for it to drain, take the container down, load the new container, start it up, run a few test cases to ensure the container is doing what it should be doing, and then put it back into rotation via Haproxy. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Any other feedback (and/or questions that I missed)?<br>
<br></blockquote><div>One thing we realized is that you have to be using host based networking. Do not try to run the containers using the docker networking that is built in. You will get some weird results. We seemed to solve all the weirdness when we moved everything over to host based networking. </div><div><br></div><div>We are beginning to work on doing compute nodes and gateway nodes. Since those don't change as often as controller functions do, we gained a lot of efficiency and speed for deployments by moving to containers. </div><div><br>We have started to look at deploying via Kubernetes. We have it working in our lab for a while now, but we are still trying to get familiar with it before we start trying to use it in production. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<br>
Josh<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br></div></div>