Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
This is not a low level docker tutorial. I will assume you are vaguely familiar with it, or you've at least cargo culted bits of docker-compose yaml and so forth. I will assume also you have a local development machine with docker installed and that you know how to git clone the demo repository at https://github.com/jjn1056/ContactsDemo.
You might notice that some of the environmental variables have funky values that look more like template placeholders. For example "SESSION_STORAGE_SECRET=${SESSION_STORAGE_SECRET}". That's because there's a .env file that contains those (you can see it in the root of the GitHub repository page. As a good practice I try to isolate anything that needs to be secret right off the top. So even though this is a development setup and would need work to turn it into a something suitable for production let's try to start off right not doing the wrong thing by hardcoding all our secrets into various files. At least now there's just one file to secure. And later on if you move to something really secure like Hashicorp's Vault product, or even something open source like git secret you won't have to hunt all over the place for the secrets to keep. Lets now look at the rest of the Catalyst application setup:
As I said before Maildev is a neat and easy to use SMTP server that is great for development since you can have your application act as though its really sending emails and have that intercepted directly and reviewed in a neat GUI application. It's a nice way to solve the problem of testing emails but you are certainly welcome to do something else, possible dangerous, like actually send emails from your development box :). Again, I want you to start thinking about chaining applications together as a cluster of single purpose containers, all talking to each other via simple conventions and environment variables (for example you might have noticed that the DB_HOST was the same as the name of the database container; Docker does a great job of offering simple conventions like that which really save a lot of setup headache.
For developing I find the official Perl docker images, running on a lightweight version of Debian, to be perfectly fine. Later on you might hand roll the skinniest possible image but the beauty of this setup is you can do that later and you don't need to change anything else. There's really not a lot going on here. First I declare the base image, which is as I said the official Perl image. I'm not using the latest Perl here because the application uses Sqitch for managing database migrations and that needs an update (there's a PR pending) to run on the most recent Perl so we'll just use a very nearly recent one instead. WORKDIR just defines where your application is installed. You can put it anywhere you want within reason. I like simple things so I use the most simple of all the conventions I've seen around.
I will recommend you review the documentation for the official Postgresql docker images which you can read here.