@@NickJanetakis it would be nice if you could cut out the "you know" because it feels like you are setting an artificially fast pace where your thinking can't keep up, and your brain is using "you know" as time padding to give it a chance to catch up,
@@Carlos-qf7sd Thanks. It's really hard to control things like that. It was an unscripted talk where I recorded the first take except for having to do the intro 30 times until I got it somewhat ok, that's why there's a little voice change early on. Some folks fill in gaps with "ums" and "ahs", I guess my weakness is "you know". Now I wonder how many times I said it through out the video.
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).
Thanks. I still like good old nginx. It's nice to use 1 tool to efficiently terminate SSL, handle gzip, redirects, set cache headers, serve static files without your app server needing to be configured for it and use resources, set country code headers, configure temporary maintenance pages, reverse proxy your app, upgrade connections, lua script support for custom behavior, etc..
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.
It's not, adding the version has been deprecated and only exists for the sake of backwards compatibility nowadays. That's mentioned in the official documentation docs.docker.com/compose/compose-file/#compose-file.
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.
Thanks. Nowadays you can use Docker Compose profiles to situationally load containers in different environments, it replaces overrides for this feature. This lets you have 1 file for all environments and no overrides. I've made videos about this more recently.
There was a hard cap of 30 minutes enforced by Docker on the talk which I wasn't made aware of until kind of the last minute. Instead of removing a bunch of content and giving a talk without much value I tried my hardest to speak as fast and as concise as I could while slamming through an unscripted live demo. Although truthfully it's not much faster than my usual pace of the ~100 other videos on this channel, I just remember making an effort to talk fast in this talk where as every other video is how I normally talk.
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": "FLASK_ENV=${FLASK_ENV:-production}"
@@mahircic I would upgrade to a newer version of Docker Compose. 1.21 is over 2 years old and is missing a number of features. I think you need 1.25+ to support env variables that start with export. In any case, I think it'll all work immediately after upgrading compose. I'd roll with the latest version based on github.com/docker/compose/release.
I do mention nginx in the video at 15:50 and suggest checking out nickjanetakis.com/blog/why-i-prefer-running-nginx-on-my-docker-host-instead-of-in-a-container because there wasn't enough time to fit all of that into the talk. That link is also referenced in the talk's notes which was mentioned in this video too github.com/nickjj/dockercon21-docker-best-practices.
can't believe I'm watching on normal speed :). Great content!
Haha thanks. Let me know if you work your way up to 2x!
new rap god in town
0.8x is the sweet spot :) Great Info!
Stuck at 0.75x
Very informative. And wow you talk fast!
Thanks. Funny enough I put up a Twitter poll recently about the pace of my TH-cam videos and about 65% said it's ok and 35% said it's too fast.
@@NickJanetakis it would be nice if you could cut out the "you know" because it feels like you are setting an artificially fast pace where your thinking can't keep up, and your brain is using "you know" as time padding to give it a chance to catch up,
@@Carlos-qf7sd Thanks. It's really hard to control things like that. It was an unscripted talk where I recorded the first take except for having to do the intro 30 times until I got it somewhat ok, that's why there's a little voice change early on.
Some folks fill in gaps with "ums" and "ahs", I guess my weakness is "you know". Now I wonder how many times I said it through out the video.
Oh wow! Great job, Nick!
Thanks.
Great stuff Nick. I learned a lot!
Thanks for watching.
I learnt so much from this, cheers Nick!
No problem!
really usful, thanks Nick
No problem, thanks for watching!
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).
Thanks. I still like good old nginx. It's nice to use 1 tool to efficiently terminate SSL, handle gzip, redirects, set cache headers, serve static files without your app server needing to be configured for it and use resources, set country code headers, configure temporary maintenance pages, reverse proxy your app, upgrade connections, lua script support for custom behavior, etc..
Amazing talk - lots of useful tips.
Thanks, happy to hear you liked it.
Learned so much, thank you! 😍🙏🏻
No problem, thanks for watching.
Great content Nick, thanks for your efforts.
Btw, its @ 2x by default 😂
Thanks a lot. Funny enough it only sounds normal to me if I listen to it with TH-cam's 2x speed, otherwise it's too slow.
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.
It's not, adding the version has been deprecated and only exists for the sake of backwards compatibility nowadays. That's mentioned in the official documentation docs.docker.com/compose/compose-file/#compose-file.
@@NickJanetakis Thanks. I looked more into it. Docker's documentation is... a challenge to decipher to say the least lol
@@dylanleisler5327 Oh yeah, there's a lot to it and information sometimes exists in different spots with different information.
"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:
There's always 0.75x!
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.
Thanks. Nowadays you can use Docker Compose profiles to situationally load containers in different environments, it replaces overrides for this feature. This lets you have 1 file for all environments and no overrides. I've made videos about this more recently.
What's the hurry Nick?
There was a hard cap of 30 minutes enforced by Docker on the talk which I wasn't made aware of until kind of the last minute. Instead of removing a bunch of content and giving a talk without much value I tried my hardest to speak as fast and as concise as I could while slamming through an unscripted live demo. Although truthfully it's not much faster than my usual pace of the ~100 other videos on this channel, I just remember making an effort to talk fast in this talk where as every other video is how I normally talk.
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": "FLASK_ENV=${FLASK_ENV:-production}"
Do you have a .env file present? Also what version of docker-compose are you using? You can check with --version.
@@NickJanetakis thanks for answer.
Docker-compose version:
docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
I have .env file present with:
cp .env.example .env
@@mahircic I would upgrade to a newer version of Docker Compose. 1.21 is over 2 years old and is missing a number of features. I think you need 1.25+ to support env variables that start with export. In any case, I think it'll all work immediately after upgrading compose. I'd roll with the latest version based on github.com/docker/compose/release.
@@NickJanetakis This is solved my problem, thank you Nick, your videos are amazing
@@mahircic Thanks, happy to hear it worked.
Damn you’re speaking fast lol
That's the way I roll!
you don't even mention nginx in this video
I do mention nginx in the video at 15:50 and suggest checking out nickjanetakis.com/blog/why-i-prefer-running-nginx-on-my-docker-host-instead-of-in-a-container because there wasn't enough time to fit all of that into the talk. That link is also referenced in the talk's notes which was mentioned in this video too github.com/nickjj/dockercon21-docker-best-practices.
A bit too fast for me.
Instead of docker-compose.override.yml in this case, it's better to use profiles, inside docker-compose.yml ( docs.docker.com/compose/profiles/ )
They are available to use but they're still limited. For example there's no way to define a depends_on for a specific profile.