Just a few tips for who wants to dig further on Docker and CI: 1. It is better to copy the pyproject.toml and poetry.lock files after installing poetry, since those files can change often and will invalidate the cache of the layers (instructions) after them; 2. Instead of using build args to build the dev or production container, one can use multi stage build to create a dev image with everything installed, and a production image starting from scratch/distroless images and copying over only the bare minimum to run python and the app. 3. You can reverse the deployment logic and use GitOps principle with a service like portainer - you create a docker compose file that you will commit to a repository monitored by portainer, so that when you update the version (it can be done by hand o via automation) it detects the changes and updates the running configuration.
@@Tyzer126 It seems that I cannot post links, I already answered to @putnam120 but I can't see my post. search for "chainguard wolfi python" in google, choose the "Image Overview: python" page and look at the "Usage" section
Great base to start. At the end consider giving a list of short examples that are out of scope for the video that people can continue in. Theres a lot more topics that people can learn to get the deployment production ready. Docker swarm, k8, revproxy for multiple services, letsencrypt, hosting templating tools like nginx-ui, load balancers for uptime, deeper testing methods, etc. This topic is endlessly large and many people dont know where to begin searching.
It's also important to talk about versioning - maybe for a single personal website it's not that important. When working in a multi-server environment (e.g. dev/test/prod) it's critical, and also when deploying into multiple servers (e.g. k8s cluster, especially when using blue green deployment or similar)
2:34 For the docker I usually don't install poetry itself as it adds up to the size, i create separate docker-requirements file which i use to install all the dependencies. I also use a slim version of python for the same reason.
@ArjanCodes Docker is great. Extra work is usually required, however, to run the image on different CPU architectures. Maybe a short video about the challenges/solutions for multi-architecture development and deployment is helpful since Arm is an increasingly targeted? (M1+, Graviton, Pi, etc.). (i.e. Arm is now the preferred arch for most of our workloads on AWS). (Note: Fun projects I've done is to deploy simple services like you demonstrate on Raspberry Pi or an old repurposed Android phone. They are surprisingly capable and the latter has a UPS!) Thanks for the great content...you're the gold standard for easy to understand design pattern learning.
Nice video! However, containerization doesn't really automatically solve architecture compatibility issues. For example, if you build a container image with a compiled Rust application on an x86 system, it won't run on an ARM system. What you can do is using Docker Buildx and configure it to build images for multiple architectures.
The owner of the company I work for is said to be conservative and old-school - he wants to have as much as possible of what I develop hosted on-prem, so that's what I give him. Maybe he's more modern than I thought :)
8:10 ehm scaling, the magic word that pops up each time as a problem description for a modern software engineering.😂 My answer to this: unless you are doing heavy datamining, etc, make sure your app works on a single VM, use any caching, proxy,patterns if needed. ymmv 🇩🇰
Indeed, a persistent volume will work. Personally I prefer using a separate, hosted database service. That will have things like backups, sharding, access control etc built in, which is nice.
So, one little quibble about Docker. Since linux can be on multiple architectures, you can't necessarily run your docker image on all Linux boxes. If you build on an image that only supports x86, you're limited to x86, etc. This can be a problem if you're on a newer mac and your hosting service is running on x86, ending up with a "Works on my machine, but not in CI!" situation. So, one "gotcha" to be aware of.
Great video as always Arjan. May I suggest a video on the topic of handling secrets. For example In this video you needed a SSH_PRIVATE_KEY in order to connect to the VPS. It would be great to have your insight on we should handle such secrets. Thanks for sharing.
Would using VPS still have the same scaling issues? Or do they have some auto-scaling option that automatically increases your cpu/network/ssd/ram and scales them down as your application needs them?
Great guide until you started deploying it on a VPS. So much wrong with this method. What happens when your VPS needs package updates? Or when the container goes down? Or the server goes down? This method you've outlined is only useful for a hobbyist that doesn't care about uptime.
Nothing wrong with this method, just incomplete. Im assuming you prefer baas or lambdas, but arjans method can scale horizontally just fine. Setting up a docker swarm or k8 on 2 or 3 seperate vps is more then solid enough. Honestly is rather worry about the incomplete web deployment where he doesnt go into detail about protecting the endpoints with a load balancer or even just a reverse proxy with nginx or something similar. Especially if you start hosting multiple services.
@@CRutgerXWhere do I study all this man? I can build Rest Api in flask lol, but all this system design kind of stuff. I want to learn it all at one place and implement it
