Docker AKA Containerized Infrastructure

[lcreid]

We should consider containerized infrastructure.

Advantages

• Reduce the need for Jade Systems and WeenhanceIT to support a lot of our own infrastructure builds. Docker has pre-built Postgres, MS SQL Server, Nginx, Redis, Ruby, and other containers. Currently, we have both this project, for setting up the server and individual sites, and the Vagrant box builds that would require significant new development to build new Ubuntu 20.04 boxes. This project never did get the Redis install converted into the new Ruby implementation with tests, so there's a gap there that would need to be filled if we continued with the non-containers approach
• The development model is more naturally close to the production model. The containerized development environment would involve a stand-alone Postgres server or a stand-alone Redis server. It would also be more practical to spin up an Nginx container to test the production configuration
• Looks like it will be lighter weight, at least on Linux workstations
• May afford some cost savings for production deployments -- although to take advantage of them on AWS we probably have to learn a whole new set of AWS complexities
• More people are doing containers than Vagrant, so there are more resources on-line
• Some of us can probably leverage some work time to learn about and practice Docker

Disadvantages

• Time spent learning the new technology
• Uncertainty whether we'll have more "it works for me" issues because the container technology has to provide different amounts of VM support, depending on the host workstation
• The above is perhaps better expressed as: Linux workstation users will have the smoothest experience. macOS and Windows users may have to do more work to get things running and keep things running
• Surprises down the line where things don't work the way we had hoped
• It's not the Rails way to do things, if you want to work on Rails itself or submit PRs to Rails (but why not do our own thing)?

Outstanding Questions

• How to deploy? You're supposed to deploy containers. Does it make sense to do a Capistrano deploy to a container? I suppose we could
• What's the model for static web sites? Do they get their own container? What does that container look like?
• How to manage the Nginx configuration files in staging and production? This may take us down the path of the Kubernetes-like tools -- yet another level of tooling
• It seems like Dockerfiles need to change based on the host OS. May need some investigation here to see if it's true

To Do

• Try a development environment for one of our apps (probably Outages or the Dashboard home site)
• Write up the production deployment model AKA figure out how to put Nginx in front of multiple containers

Links

• Docker install: https://docs.docker.com/get-docker/
• Docker on Windows, by Microsoft: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-10-linux
• An interesting blog post by someone who's name I think I've seen in the Rails world before: https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development. Their experience using Docker for Rails development
• Rails on Docker: https://github.com/docker/labs/tree/master/developer-tools/ruby. I think I'd seen this before. It reminds me of all the reasons I didn't think I wanted to use Docker.

[lcreid]

About the deploy -- There seems to be two angles here:

• Reconciling the Rails way of deploying with containers, meaning arranging for assets to get pre-built for production-like environments, executing migrations exactly once, and other issues mentioned in the "Rails on Docker" page above. This topic may have many possible solutions, some of which might depend on the next bullet
• Setting up an environment that allows us to run multiple web applications behind the same IP address, AKA the same web server/proxy/Nginx. Some of the problems in the first bullet can be solved by making the whole EC2 server a single Docker environment, e.g. assets can be in volumes that we can share between the Nginx container and the application container

I need to learn more about deploying Rails in containers.

[lcreid]

There seems to be a pretty hard stop in terms of choosing Docker or Vagrant: If you're using Vagrant your database server is on localhost, and if you're using Docker it's on another machine (typically postgres). Some environment variable trickery might fix this. Set environment variables in docker-compose.yml and default to the Vagrant ones if not set.

[lcreid]

Part of the complexity of the original set-up scripts, that turned into the small Ruby application, was that we have to set up an HTTP version of the site, then get the LetsEncrypt certificates, then switch to HTTPS. It looks like certbot can now modify the Nginx config automatically. You just run the certbot with an HTTP site and it becomes HTTPS. https://certbot.eff.org/docs/using.html#nginx

[lcreid]

I've solved the database host issue to be Vagrant and Docker friendly by having docker-compose.yml set an environment variable for the host, and modifying database.yml to use the environment variable and default to localhost if the environment variable isn't set.