Looking to upgrade my audio setup with a Blue Yeti USB microphone! If you'd like to support the channel, you can buy me a coffee here: ko-fi.com/thecodinggopher.
@debbie80626 күн бұрын
another great video on Kubernetes!! this really is the only video i needed to understand containers 🤯
@TheCodingGopher6 күн бұрын
🚀!
@AdrenalineAkash136 күн бұрын
Clean Concise and to the point. A great way to begin with #Docker
@TheCodingGopher6 күн бұрын
Appreciate the comment
@gabrielcanaple34795 күн бұрын
incredible video man, although i've been on the development side, i was curious about the deployment and orchestration magic and you made it really clear ! thanks man
@TheCodingGopher5 күн бұрын
It's my pleasure, thank you for tuning in
@abdulsamadayoade9439Күн бұрын
detailed and straight to the point, thank you
@TheCodingGopherКүн бұрын
My pleasure, cheers
@JokerAobКүн бұрын
Great video and very good explanation!
@BrunoBernard-kn6vt5 күн бұрын
Amazing! Can you talk about Docker Swarm / Docker Stack?
@TheCodingGopher5 күн бұрын
Yes, added to my ideas list!
@xthefrancisxify3 күн бұрын
Awesome video
@TheCodingGopher2 күн бұрын
Cheers
@marhensa3 күн бұрын
if my project is only small scale, I only need portainer right? also another question which is better podman or docker?
@debbie80623 күн бұрын
For small-scale projects, Portainer can indeed be sufficient. It provides an easy-to-use interface for managing Docker containers and simplifies tasks like deployment, monitoring, and volume management. However, if your project grows in complexity or scale, you might eventually need to delve deeper into Docker or Podman for advanced features.
@TheCodingGopher3 күн бұрын
Yes; Portainer is enough for small-scale projects (also has a nice GUI). It's a bit hard to say which is objectively "better", but here's a comparison. Podman is rootless (i.e. don't need admin), more secure, no daemon required. Better for local development or envs with strict security needs. Docker is more mature, has broader community support, and integrates well with CI/CD tools. It's better for production / larger ecosystems.
@MichaelScharf4 күн бұрын
Where does docker compose fit into the picture?
@TheCodingGopher4 күн бұрын
Docker Compose manages multi-container apps with a simple `docker-compose.yml` file; good for local development. Kubernetes handles container orchestration at scale; good for production environments.
@MichaelScharf4 күн бұрын
What do you think something like portainer that allows you to run docker compose files without the overhead of kubernetes?
@TheCodingGopher3 күн бұрын
@@MichaelScharf Portainer is a great lightweight alternative for managing Docker Compose files without the complexity of Kubernetes; very solid for smaller-scale / local deployments.
@TheCoder-1924Күн бұрын
@@MichaelScharf you use it with docker swarm. docker swarm and docker compose combo is good
@Ryan11lv4265 күн бұрын
I think a few examples of better comparisons would be: - docker swarm vs kubernetes since those are both orchestration platforms - docker engine vs podman since they handle the lifetime of their containers differently - lxc vs docker since there is large differences in how containerd and lxd interact with the os/kernel/containers Hopefully not too critical your mic was fine and you pulled good diagrams in, but my opinion is it's a long video to say docker is a runtime package used in industry mainly for building images (it does have an engine to run containers on a single machine). While kubernetes is an orchestration platform for managing running containers across multiple nodes/machines.
@TheCodingGopher5 күн бұрын
This is a common challenge I often face. The audience for this video is quite diverse in terms of skill levels / YOE. This video serves as a basic introduction to Docker and Kubernetes concepts, aimed at developers who are newer to these topics and looking for a soft introduction. At the end, I clarify that Docker and Kubernetes are not an either/or choice; they’re complementary and can work together in a hybrid approach. That said, you make valid points about better comparisons. I’ll take note of them and consider creating a follow-up video focused on Docker Swarm vs. Kubernetes, and I'll incorporate the other comparisons as well. Cheers.
@ighor3 күн бұрын
Everything you said is wrong unless you replace 'Docker' with 'Containerd'. Docker itself is also an orchestrator and supports scalability. Both Docker and Kubernetes are using Containerd to run images. It would be worth comparing Docker vs Kubernetes, explaining at least that the first one can work with local hardware and the second one can't, the second one supports lots of filesystem and network drivers and the first one doesn’t.
@TheCodingGopher3 күн бұрын
That's not quite accurate; there are a few incorrect blanket statements. Docker itself is not an orchestrator. While it supports Docker Swarm for orchestration, its primary role is as a container runtime. Containerd is the actual container runtime used by both Docker and Kubernetes to run containers. In the video, I made the distinction between local development with Docker (which works well on a single machine) and production environments with Kubernetes (which is designed for scaling across clusters). As for file system and network drivers, Docker supports various drivers through its plugin system. While Kubernetes may have more built-in drivers, Docker integrates well with these through its ecosystem.
@ighor3 күн бұрын
@@TheCodingGopher Docker is not integrates well with Kubernetes drivers. Docker can’t use these Kubernetes drivers unless it’s image running inside a Kubernetes cluster
@TheCodingGopher3 күн бұрын
@@ighor You are partially correct; but here's more context: Docker doesn't "use" Kubernetes drivers directly because Docker is a container runtime, while Kubernetes is an orchestrator. However, when Docker containers run in a Kubernetes cluster, they indirectly rely on Kubernetes' drivers since Kubernetes controls the underlying infrastructure via Containerd. Docker has its own drivers (via plugins), but in Kubernetes, Containerd handles the runtime, and Kubernetes manages the drivers.
@ighor3 күн бұрын
@@TheCodingGopherDocker containers can’t run in Kubernetes, that method is deprecated. Only container images run in Kubernetes, and they are not related to Docker at all. There is no easy way to run Kubernetes storage drivers in Docker alone. This important note is rarely mentioned, and it’s worth highlighting when comparing the two
@TheCodingGopher3 күн бұрын
@@ighor Good callout. Looks like Kubernetes no longer relies on Docker as a container runtime since the deprecation of DockerShim. Instead, it uses container runtimes that support the Container Runtime Interface (CRI), like containerd / CRI-O. Docker images can still be used in Kubernetes though (since they're OCI-compliant).