[Don't Merge] Dockerfile for Peril

[rgbkrk]

Um... yeah, the inner hipster in me decided to stop developing on top of my mac and instead use a VM or container.

[smashwilson]

So, this is cool, but... if we do want to go the Docker route for packaging and deployment, there are a few things we'd need to address.

• [ ] First of all, we'd really want three containers for the full app: one for peril-web, one for peril-poll, and one for PostgreSQL. Maybe a fourth to launch and link the other three.
• [ ] How do we protect credentials and Secret Code :tm:? Remember we've got two source files full of API keys and stuff. Would a private container on dockerhub be enough protection?
• [ ] What about all of the other stuff the Ansible playbook already does?

[rgbkrk]

Yeah, you'd need separate containers for each. I was slightly cheating while using this by running

docker run -it peril bash

and then launching multiple processes (a no-no)

For creating independent Dockerfiles, it can be done. They just need their own directory. This goes back to me poking at them being separate projects, possibly sharing a library/gem.

and one for PostgreSQL

Yes, Postgres would live in its own.

Maybe a fourth to launch and link the other three.

Launching and linking them happens outside of Docker.

How do we protect credentials and Secret Code :tm:? Remember we've got two source files full of API keys and stuff. Would a private container on dockerhub be enough protection?

Environment variables are the "right" way to do this :tm:.

docker run -e "SOMESECRET=coolbean" blah

Not sure the private container is a good idea.

What about all of the other stuff the Ansible playbook already does?

Make Ansible create the Docker containers within a Dockerfile?

[smashwilson]

For creating independent Dockerfiles, it can be done. They just need their own directory. This goes back to me poking at them being separate projects, possibly sharing a library/gem.

:thumbsdown:

peril-poll and peril-web share the same set of active Slurpers and Notifiers, model objects, configuration, and other context. They communicate through the database. So we'd need three gems to separate them, and it would be a giant mess again.

Together, each Slurper is maybe 50-100 lines of Ruby. Apart, there's a bunch of boilerplate and dependencies and setup that they'd all need to share, and we introduce a ton of version management overhead that simply isn't necessary.

I deleted so much code and cleaned up so much mess combining everything here, I don't want to lose that work.

Launching and linking them happens outside of Docker.

I was thinking of that one project we saw that had a "coordination image" that mapped the Docker socket and launched and linked all the others, as a convenience.

Environment variables are the "right" way to do this .

:thumbsdown:

We're going to have to define an entire Notifier implementation in notifiers.rb. Packing that into an environment variable is going to be an enormous pain if it works at all.

Overall, I think going the docker route would make this wildly more complicated for no gain. Furthermore, it's already running on a host, and we have an Ansible playbook that works fine, with all of the templates and secrets and such in place and secure. Docker is cool, but does it actually buy us anything here?

[smashwilson]

Er, sorry if I was harsh there! I'm trying to focus on getting the final bits connected to start using this as a real system and I'd rather not rework the deployment pipeline until we've got something working end-to-end.

The notifiers.rb and slurpers.rb configuration problem is bugging me though. You can share individual paths from the host system with a specific container by -v, right? I bet we could use Ansible to lay down the templates chock full of juicy secrets, then pass them in to the peril-poll and peril-web containers via file share.

[rgbkrk]

Yeah, my intention wasn't to change the deployment setup. I just wanted something quick to work with on a fairly fresh Mac. I think I answered your questions too literally, as if we needed those answers.

As for configuration, they can share a volume together using -v. That sounds pretty good and doesn't have to live on a private index.

[smashwilson]

Yeah, my intention wasn't to change the deployment setup. I just wanted something quick to work with on a fairly fresh Mac. I think I answered your questions too literally, as if we needed those answers.

Whoops! Yeah, I'm sorry. I totally read this as "Hey Docker is cool let's rewrite our deployment pipeline to use Docker!!!" With all three exclamation points.

By the way, hey, Docker is cool! Let's rewrite our deployment pipeline to use Docker! (Eventually)

[rgbkrk]

Closing old PRs.

[rgbkrk]

Funny looking back at this one. Closed at my own peril.

I'll show myself out.

[smashwilson]

Hah, you caught me in a bad mood on this one. Sorry about that << >>

[rgbkrk]

Heh, no worries here. 😜