How are you managing CI/CD for your nginx configs?

[Peter Booth]

I’ve tried chef, puppet and ansible at thre different shops. I wanted to like chef and puppet because they are Ruby based (which I like) but they seemed clunky, ugly, and heavyweight. Ansible seemed to solve the easy problems. When I had a startup I just used Capistrano for deployments, with erb as a templating tool tool to generate config files and to pregenerate static web pages. What could easily have been a rails, php or servlet based dynamic app instead became a static website that was rebuilt whenever the rails based admin tool modified metadata.

 This enabled a number of things:

Multiple nonproduction versions of the site coexisted:

Qa1.mysite.com
Qa2.mysite.com
..
Qa5.mysite.com

With a latest.mysite.com tgst would cycle thru qa1 thru qa5 and round again

Sent from my iPhone

> On Jul 17, 2018, at 1:38 PM, Friscia, Michael <michael.friscia at yale.edu> wrote:
> 
> I prefer simple setups that start with the question, "What is the least I can do to manage this new thing?" 
> 
> I've worked with all the various things mentioned below like Chef, Puppet, Ansible and many more but scaled everything back to keep it really simple this time. I have 6 Nginx servers (pairs of servers running in USA, Europe and Asia) and we run about 800 DNS names through them as either redirects or full vanity URLs using about 70 configuration files. These are all Linux and all running Nginx-Plus. 
> 
> I put all my configs in a single directory, everything that is .conf is included then I use .inc to include only where needed in specific server or location blocks for the sake of code re-use.
> 
> This is all in a git repository. 
> 
> Each server has a cron setup to run once a minute with an offset so that the crons run 20 seconds apart and in 2 minutes time, all servers will patch up to the latest version. The cron basically just does a git pull and if an update is needed, it deletes the conf directory in the Nginx install location, copies all the files from Git and then restarts Nginx.
> 
> Inside the Git repo is a file I call autodeploy.act and that file is a list of the servers by name with a 0 or 1 at the end. When the cron runs, it compares the current server name to the list in this file and if the number is a 1, it runs the update, change the number back to 0, logs that it updated and then commits the changes back to GIT.
> 
> My actual workflow goes like this. I make changes and commit them to Git using Visual Studio Code with the Nginx color and tag plugins. I go onto my dev server and run a deployment bash script that replaces all the conf files, restarts Nginx and then runs a bunch of cURL commands to make sure I get back HTTP 200 responses. Then I know that I didn't break Nginx and I can then set my local HOSTS file to point to this dev box and perform some tests. If all goes well I open up the autodeploy.act file and change all the 0's to 1's and after a couple minutes run a git pull and see that my changes are live, edit my local HOSTS file back to normal and test my settings.
> 
> My goal was to install as few things on these servers as possible. Basically they all run Git and Nginx and that's it. I did not want to get involved with Chef, Puppet, Docker or anything too fancy since the goal is pretty basic. I want to replace some files and restart a service. Bash and Cron had all I needed so I decided to make this as simple as possible. I'm all for using these other tools, but I don't like to force tools on a problem that can be solved with everything built into the operating system. I mostly did not want to then have to apply patches, updates and all that to yet another product.
> 
> In any event, I hope someone might find this approach useful. 
> 
> ___________________________________________
> Michael Friscia
> Office of Communications
> Yale School of Medicine
> (203) 737-7932 - office
> (203) 931-5381 - mobile
> http://web.yale.edu <http://web.yale.edu/>
> 
> 
> On 7/17/18, 1:12 PM, "nginx on behalf of Jason Whittington" <nginx-bounces at nginx.org on behalf of Jason.Whittington at equifax.com> wrote:
> 
>    Last year I gave a talk at nginx.conf describing some success we have had using Octopus Deploy as a CD tool for nginx configs.  The particular Octopus features that make this good are
> 
>    * Octopus gives us a good variable replacement / template system so that I can define a template along with variables for different environments (which really helps me ensure consistency between environments)
>    * Octopus has good abstractions for grouping servers into roles and environments (So say, DMZ and APP servers living in DEV, TEST, and PROD environments)
>    * Octopus has a good release model and great visibility of "which release is deployed to which environment".    As in "1.2.2 is in dev, 1.2.1 is in test, 1.1.9 is in production"
>    * Octopus has good security controls so I can control who is allowed to "push the button" to deploy dev->test->prod
>    * Octopus can be driven via APIs and supports scripting (particularly powershell) that can be used to interact with other APIs.   When I demoed this at nginx conf I was using mono on the nginx VM to invoke bash scripts.
> Yet
>    The only problem is thŚat Octopus is a very Windows-centric product.  I'm interested in doing this same sort of management using a "linux-centric" toolchain and would be interested to hear what tool chains others might be using.  Ansible?  Jenkins?  Puppet/Chef?
> 
>    The process I describe above is what we do with servers that are relatively long-lived.  I would also be curious what toolchains you've found to be effective when servers are more transient.   E.g. do you build server images that have the nginx config "baked in"?  Or do you stand up the VM and push configs / certs in a secondary deployment step.
> 
>    Thanks!
>    Jason
>    This message contains proprietary information from Equifax which may be confidential. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmaster at equifax.com. Equifax® is a registered trademark of Equifax Inc. All rights reserved.
>    _______________________________________________
>    nginx mailing list
>    nginx at nginx.org
>    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.nginx.org%2Fmailman%2Flistinfo%2Fnginx&data=02%7C01%7Cmichael.friscia%40yale.edu%7C68137d1ab37d468cc2b608d5ec088447%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C636674443701504484&sdata=8RjRRKE9%2BXGlV2vcPTLKnAQhY4fA7mU6RHt8WuJbkCw%3D&reserved=0
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx