Best Practices Around Production Ready Web Apps with Docker Compose

REFERENCE LINKS
---------------------------------------------------

COURSES
---------------------------------------------------
Courses I've created that focus on web dev and deployment topics.

THE TOOLS I USE / GEAR
---------------------------------------------------

FOLLOW ME ELSEWHERE
---------------------------------------------------

TIMESTAMPS
---------------------------------------------------
0:00 -- What we're going to cover
0:19 -- Who is Nick?
1:20 -- All reference links will be in this GitHub repo
1:31 -- Our example app's tech stack and how it's similar to a lot of web apps
2:20 -- Quickly viewing what the app looks like and jumping into the code
2:53 -- Not defining a version property to stick to the Docker Compose spec
3:21 -- Using a Docker Compose override file to pick what you want to run in dev and prod
7:11 -- Reducing YAML duplication with aliases, anchors and Compose's extension fields
10:56 -- Tweaking your health check with an env variable for dev vs prod
13:05 -- Creating a health check endpoint to test your db, redis and app's connectivity
14:40 -- Restricting port forwarding so only localhost can access certain services
17:08 -- Adding resource limits to your container's CPU and memory
17:39 -- Changing around your container's restart policy in dev vs prod
18:42 -- Changing around your volumes to only bind mount your assets in production
19:57 -- Configuring your app server's bind host and port
20:49 -- Configuring your app server's worker and thread count
21:55 -- Configuring your app server to log to stdout so you can let Docker send logs elsewhere
22:32 -- Configuring a managed database in production while using a local db in development
24:04 -- Taking advantage of multi-stage Dockerfiles to optimize your main app's image
24:24 -- Best practices change over time, don't be afraid to do things differently in the future
24:52 -- Running your containers as a non-root user
25:27 -- Customizing where package dependencies get installed to avoid volume issues
26:29 -- Taking advantage of Docker's layer caching and glancing over a PurgeCSS specific line
26:56 -- Using build arguments to set our app's env so we can situationally bundle our assets
28:15 -- Copying in our Webpack stage's bundled assets into the Python application
29:03 -- Going over a few things in the Python app's build stage
30:36 -- Setting a few useful env variables for Python and digesting your static files
31:14 -- Configuring an EXPOSE port so we know what port is being used in the container
31:26 -- For the CMD, use the array syntax instead of a string so your process is PID 1
32:02 -- Using an ENTRYPOINT script to clean up and prepare digested static files
33:09 -- If you're interested, I have a course on deploying web apps with Docker coming out

[merridius]

can't believe I'm watching on normal speed :). Great content!

[derberherbert]

Very informative. And wow you talk fast!

[gediminasz]

Some solid tips here. I've been running a similar setup for my hobby project with great success.
If someone is looking to further strip down some of the complexity, I would suggest to choose SQLite as your database, Caddy as your webserver, and also serve your static files from Flask/Django/etc (usually frameworks have such capability).

[ToadyEN]

I learnt so much from this, cheers Nick!

[AmarjeetAnandsingh]

Great content Nick, thanks for your efforts.

Btw, its @ 2x by default 😂

[dylanleisler]

version: "3.4" is needed at the head of your file for extensions (the x-app header that he demonstrated) to work. Extensions were added in 3.4 and should be available to all versions after that.

[HarryMcKenzy]

"not quite my tempo !"
jk, it's exactly my tempo and the stuff i learned in this talk is AMAZING ! thank you very much Nick :thumbsup:

[scottfredericksen]

Good information in here Nick. But, I really hate the "x-app" export stuff and I hate the docker-compose-override.yml stuff. I don't like "override" because you have to create a second file anyway (as opposed to just having both a Compose "prod" and "dev" file). So, then you have to load into your brain which things are overriding what when in Dev. I'm never working in Prod and Dev at the same exact time, so when I'm in Dev, I'll focus on my Dev environment and when I'm in Prod, I'll focus on my Prod environment and just have a single file open that contains all of the relevant configuration information in one file. As I type this, I guess I see that in Prod, you would only have one file also, but I guess I'm in Dev more than Prod, so I prefer to have everything in that one docker-compose-dev.yml file. And, similarly for the "x-app" export stuff... I would just rather have all of that stuff in each section so I can reason about it with out having to remember (or scroll up) what was configured for it at the top of the Docker Compose file.

[mahircic]

can somebody helps me, i get error when i try to deploy docker-compose file:
ERROR: Invalid interpolation format for "build" option in service "x-app":

[DakotaCarter]

you don't even mention nginx in this video