Even if Okteto is "simple to use" it does not remove complexity of dealing with k8s. You cannot remove complexity with handful of abstractions and simplified workflows - it's still there and sooner or later it will bite you. See "Law of Leaky Abstractions". In larger team context I personally would rather have a lighter docker-compose workflow, but at the same time give developers ability to launch the app in minikube as well. So they at least have a chance to familiarize how production looks like and have a "sandbox".
I do agree that k8s is more complex than Docker Compose. If k8s is too much then we should not use it. What I'm saying is different. I'm saying that if one did choose k8s, then using it in some environments and switching to Compose for others is more complex and leads to inconsistent results. If, let's say, we already have Helm charts used to deploy apps to production, isn't it easier and better to use those same charts in dev? Docker Desktop already runs Kubernetes. As a side note, one does not need Okteto to do what Compose does. A simple `helm install` does that with the manifests that already exist. Okteto adds additional capabilities that do not exist in Compose. P.S. I'm using Helm as an example. It could be Kustomize, ytt, or anything else used to define and deploy apps to k8s. The point is that if manifests already exist, a single command is required to run them in dev.
Nice to stumble across this video! I've evaluated most of the kubernetes development environment tools like Garden and Tilt, and Okteto has been the best fit for my team. The reverse port forwarding functionality, enabling remote PHP debugging, was one of the key differentiating features for us. So for the past few months we've been working on adopting a self-hosted Okteto solution as our development environment. Working great so far!
Would be interesting to see a comparison of Okteto, Tilt, and Skaffold (I see others have asked for it). What's in one and not in another, what do they have in common (and how do they implement it differently), and when to prefer one over the other. Based on your experience/opinion, of course. You might not be able to do such a comparison in 30 min. 🙂
It's coming as a part of a new project (series) I'll start working on in late January 2023. I'm not yet sure whether all three of those will be there. It'll likely be Okteto, DevSpace, and Telepresence (due to reasons I cannot reveal just yet).
For me the main benefit of docker compose is the simple management of dev dependencies like database or message queue for which I don’t have k8s manifests as on prod I usually use managed services of some cloud provider.
Isn't it just as easy to add the db as an optional dependency in the helm chart of the app itself (the one used in production). Actually, that should be easier since you do not have to define the chart itself (assuming you're using helm in production), but only the dependency (the db).
What is the reasoning behind not using docker-compose in production? I know all the extra goodies that come with k8s eg: auto scalability, better fault-tolerance and .., but not all projects have such requirements. Can you elaborate your vision on that?
Apart from "all the extra goodies", it's about the investment. If you already have it running with Docker Compose and it does what you need it to do, great. Keep it. But, if you're investing in something, you want to try to invest in something that has a future, and Docker is not it when production is concerned. Even Docker (company) itself gave up on it. Everyone is using and investing in Kubernetes. Whichever innovation or solution to a problem you might need, it's likely in Kubernetes. You need better storage? Kubernetes. Mutual TLS? Kubernetes. Progressive delivery? Kubernetes. And so on and so forth. We all make mistakes, and it's unavoidable that the part of investments we make (time, money, etc.) will end up being a bad choice or become obsolete. However, that does not mean we should make choices based on things that are obviously a dead-end. No one is investing in Docker Compose or Docker Swarm for production. Nothing new is coming, and existing projects are not maintained (much). All in all, if you are already using Docker Compose in production, keep it as long as it does what you need it to do. The moment that stops being the case (the moment you need to add something to it or invest more time into it), move to Kubernetes. The same goes for Mesos and Nomad. Those are great platform as well, but they are, just as Docker, on life-support when production is concerned. Almost no one is investing in them. Also, not all Kubernetes-based services are complicated. Far from it. Kubernetes alone is the base, not the end-user solution. Take a look at Azure Container Apps. They're easier than anything, better than Compose, users do not see Kubernetes, but it's running in Kubernetes. Or you can choose Qovery, or any other out of many solutions that provide much better results than Docker alone, that are based on Kubernetes, yet eliminate complexities of Kubernetes. P.S. Docker itself is NOT dead. It's thriving as a developer experience tool. When I say NO to Docker, I mean NO to using Docker in production or any other permanent environment.
Everytime I've tried to use a development Kubernetes system, it has broken badly all by itself at some random time, requiring it to be completely removed and reinstalled. I just want something that just works, every day. Docker compose just works.
It all depends on what you do in Kubernetes. If you reproduce what Compose is doing, there is very small chance or breaking or things going wrong. It's a Deployment with a Service resource. That's it. Compose does not have an equivalent of much more than those two. Now, if you go full throttle on Kubernetes, you are introducing additional features that, typically, do not exist in Compose. It can be something as simple as Ingress towards more complicated stuff like progressive delivery, serverless, etc. Those are more likely to break, especially if one is not experienced with them. However, that is not directly comparable with Compose since it does not have those features. Nevertheless, you're right. Compose works. It's simple (for today's standards) without doing much (compared to k8s), but what it does it does well. You'll have to deal with the risk of having differences between what you're using in dev and what's in production, but that's a separate discussion.
greenfield projects should do everything possible to use open source software so all runtimes can be available in development. Then seed test data locally.
1:30 maybe mixing up staging/testing environment with developer environment 👀? The production environment is usually an artifact of the development environment. Meaning in dev we have a full stack application running with websockets for hot reloading via a node.js server but in production it’s a static website serving from the /build folder. A docker compose has node etc while the kubernetes manifests do not. If they would be the same, we would ship node.js, android studio to the cloud. Docker compose in combo with i.e. tiltdev provides a very replicateable turn key developer experience while the kubernetes manifest is providing a replicateable production environment. Spinning up a production system per pull request is totally the right approach though orthogonal to docker compose. Different use cases. Love your content ❤️
For production env, the deployment manifests are stored in a separate git repo (picked up by ArcoCD). Should we have manifests duplicated in the repo where we want to do Okteto or what is the best practice here?
Argo CD app should reference a repo with manifests and include environment specific parama. That means that the manifests themselves can be anywhere, so why not keep them where the rest of the code of the app is?
@@DevOpsToolkit well, b/c commit to the repo with code will trigger CI/CD proceeds which will produce new image which should be updated in deployment manifests which is another commit into same repo causing newer ending loop…
@@DevOpsToolkit ok so 2 repos: 1st source code + k8s manifests, 2nd with another manifests (kustomize) for argocd. Right? Currently, we have a single repo with all manifests for the app with 2 sub-folders: base and overrides/[env1…]. Do you have any reference project with such configuration? It would be very helpful to check how it done.
@@lyubomyrvyhovskyy2668 I thought you're using Helm (most common choice even though I don't like it). With Kustomize, that part is a bit trickier since you probably want to keep all overlays and the base in the same place. Still, I would keep it in the repo with the app code since I cannot imagine developing an application without being able to run it locally or remotely before pushing code changes to Git. So, I prefer using comments like `[skip ci]` to avoid triggering pipelines. Otherwise (if all the manifests are elsewhere), you're effectively forcing developers to figure out other ways to run their apps by rewriting k8s manifests into Docker Compose (or something similar) and facing the challenges of ephemeral environments being completely different from permanent ones. We had similar discussions in the past about build scripts, tests, and other artifacts produced (in the past) by other groups and, eventually, we did get to the point where all those are in the repos with the rest of the code of apps and not elsewhere.
Main question for me would be how easily it integrates into IDEs like VSCode. Remote Extension DevContainers using docker-compose is easy to use for developers
One of the things I always do with docker compose is to create a bind mount to be able to get the local dev directory onto the container and in that case the uid of the user inside the container has to match that of my local env, curious to know how okteto handles this
Any local Kubernetes spins up a VM (unless running in Linux) and is not accessible outside your cluster. It could be Docker Desktop, Minikube, or, my favorite Rancher Desktop. Now, if you're looking for a remote environment, it all depends on where your infra is. If it's on-prem, I suggest k3s (you'll still need to create a VM whichever way you're creating VMs). On the other hand, if Cloud is OK, I suggest Civo. It's fast, and it's cheap, and, I think, you can make it accessible through a VPN so that no one outside it can access it.
In that video, I did not intent to review okteto but rather to use it as an example that demonstrates that there is no need to docker compose. I'll do a comparison with devspace and a few other tools soon.
I'm not necessarily saying that everyone should move to Okteto. It's a great product/service, but the goal of that video was not that much to go deep into Okteto but, rather, to demystify the need for Docker Compose for dev and Kubernetes manifests for prod. You should check out Okteto but also note that there are other similar tools as well. Also, I hope to do a video comparing similar tools soon.
@@DevOpsToolkit Thanks. I actually develop alot with docker-compose before deploying. I will definitely explore the need to use any of the tools in dev and later in prod to simply the many things involvs.
There are some overlaps, but also some differences in how those two tools approach the problem. In this video, I picked a "random" tool since the idea was not to compare or pick a "winner" but rather to demonstrate that there is no need for Docker Compose. I already added to my TODO list "compare different tools for dev environments in k8s".
Indeed, the greatest advantage of using Kubernetes from your laptop is the scalability. I deploy kubeadm clusters but I have powerful laptops and a workstation. This is even more important if you have to deal with service mesh stuff. Okteto is a great alternative.
TBH, Docker Compose was never built for production, it was built for local development. And we have Swarm for that. But k8s is the way to go. Great video
Back in the days, there was ambition to use Compose (with or without Swarm) in production. Those days are long gone now and Docker's plans changed completely. I like the new direction heading towards dev experience.
Swarm hardly gets any new adopters, almost no project or vendor adopted it, and docker gave up on it. How can anyone talk about the future of swarm when almost everyone agreed that k8s is the base for almost all innovation?
Hey, there Kube nation, I'm a Kubernetes beginner and I'm wondering what are the the typical gotchas for beginners when using Kubernetes. Cheers and subscribed.
I think it's the other way around. You need Dockerfile (unless you're using Buildpacks) and you need Kubernetes manifests to deploy your app to production and other permanent environments. So, the question is why do you want to maintain docker-compose.yaml if you already have the manifests (e.g., Helm, Kustomize, etc.) that you can use to deploy your application to any environment? From that perspective, Docker Compose is a new tool that does not serve a clear purpose (apart from the historical perspective when many, including me, thought that Docker Swarm is a good choice for production). What does Compose give you that you do not have in your Kubernetes manifests? P.S. Dockerfile is a format to define container images and is used by any engine and not only Docker which, by the way, does not even work in k8s anymore. P.P.S. All my comments assume that production is in k8s. If that's not the case, Compose serves a purpose if you're running production elsewhere (e.g., GCR, Azure Container Apps, Lamdba, etc.) and you want to develop locally. P.P.P.S. No one should use Docker in production. Even Docker itself (the company) is not using it for that purpose internally.
If you're referring to it being cheaper than working in "real" servers/clusters, I agree. Still, running a Kubernetes cluster locally (it can be with Docker Desktop) is only a click away. A very small amount of CPU and memory is required to run a local k8s, especially if using something like Rancher Desktop based on k3s.
My use case is a little different, but I am trying to go from docker-compose to Kubernetes right now ( probably how you video go into my feed) I am struggling with getting the cni setup for my use case. I need 200-1000 containers (or pods) all with about 100 ports exposed using the ipvlan driver (so each pod/container gets it’s own up address that is reachable by other machines on the same subnet) Setting this up with docker-compose just worked, but I am struggling with kubernetes (probably because I’m so new). Also should probably mention that this is in non-cloud scenario
I was never in a situation to export more than one port. Whenever possible, I use Ingress and in rare occasions, I might expose a single port of a Service. So, I'm not sure whether that are some limits you might face. I'm assuming that you specified all those ports in the Service manifest associated with the Deployment/StatefulSet. is that the case? If it is, what did you see as the side effect?
@@DevOpsToolkit Yeah, my use case isn't for a dev/prod system, it is more of an environment used for scale testing. Each pod simulates a device that our product interacts with, ideally each 'device' would have its own IP/DNS... however we can't hit the scale we want, so we settled with 100 devices per pod (thus 100 exposed ports + 22 for ssh). The issue is that none of the Pods are not reachable outside of the k8s cluster (by their IP addresses). I looked into ingress but that doesn't seem to fit our needs (as it seems my option would be to bind container ports to the host port and only have a single IP?) With docker the IPVlan driver was used (macvlan would also work but wasn't necessary). I think k8s supports the ipvlan driver, but I can't seem to figure out how to get it working. Thanks for your reply, I wasn't expecting a response but yeah I'm still digging into this. I think it's possible, just hard to navigate because until this week I didn't even know what a CNI was.
Have you defined Services with NodePort? That should give you publicly accessible ports without ingress. If you use LoadBalancer Services you'd get the same plus LB but I guess that might be more challenging when on-prem.
@@DevOpsToolkit I did, I could hit the containers/ports if I was on the Node running the container, but it wasn't reachable from any other Node (or our other box). Maybe something is misconfigured? That is what I was hoping would work when I frst dug into this. (using a service to expose all the IPs/Ports)
my question is : how to do with ide : I work with pycharm and docker compose, and i had try a lot of time to move on rancher desktop, but each time, i couldn't setup my interpreter.
I'm not sure about pycharm (not working with it myself). As for Docker Compose... I abandoned it a long time ago. It's all about Kubernetes today, so I suggest embracing it sooner than later. Once you do, Compose will become a waste, and you'll adopt k8s-native tools instead.
One more thing... IDE is typically not an issue. You're still writing code in your favorite IDE. What changes it how we deploy, run tests, etc. That is now happening in k8s clusters (local or remote).
@@DevOpsToolkit I was not clear : with pycharm (jetbrain ide) you have a docker-compose integration for the interpreter. You create your dockerfile with a python service (for example a webservice + dbservice + redisservice) and you can configure pycharm to use the docker-compose file and your webservice to be the interpreter. You will have autocompletion, run, debug, navigation into the docker dependencies etc like a standard projet. For a big projet it's a must have. I agree with you, we want to use k8s for the dev part. Now, we have to create and maintain a docker-compose file for the dev part (and it's a big compose file), and all helm charts for production part. And of course, we loose a lot of time, because some configuration into the compose file change and we forget the helm part. I just search a solution to use k8s for the dev part, with a good integration with a good ide sry for my english Thx a lot for yours videos
@@fsx9991 if I understood this right, you can just work on your local files, but Okteto ensures your local folder is mounted into the container, hence changes are reflected immediately or are recompiled upon changes are detected (depending on the language). The advantage is, that you do not need a different way to deploy services for local development. You can just use the same way you would use for production (e.g. helm charts). I remember listening to a talk when I visited ContainerDays 2022 conference and it was really nice, though I don't think most developers are yet ready to completely give up local development and go down the Kubernetes route from the beginning.
Half of video with no real explanation and examples, just an advertising. Okteto != K8s and Compose is a configuration of the stack that runs locally out of the box and in swarm cluster as is. The okteto config is not shorter than compose one. It is the COPY of compose plus couple of sections. Okteto could easily use compose config as base configuration with custom extensions, but they prefer to develop their own format for their own specific platform. Increase the coupling with different solutions is not my way.
It is not an ad for okteto. I did not receive any compensation from them. They did not even know that the video will be published. The point I'm trying to make is that I do not see any advantage of using compose if production is in k8s. Why not use prod manifests (or variations of those manifests through helm values or kustomize) in dev? So, the question is not why compose but rather why would one have something completely different in dev and prod.
You just proclaim using Compose in production is a bad idea but then never actually back up why you think that is the case... No arguments for your position makes it look very weak imo (EDIT) we had a very fruitful discussion below!
That's my bad. I thought it was obvious. Not even Docker (company) runs it in production. Here it goes... There is no distribution across nodes (scheduling), networking is too basic, there are limited storage options, observability is bad, there is no ecosystem nor support from providers, etc. Docker never designed Compose to be something that runs in production. Docker Swarm is the one we were supposed to use, but that one died.
@@DevOpsToolkit what if I'm just deploying to an on-prem server with singular instances of the containers? No scaling. Also, there's some useful integration of Compose in Azure Devops
@Ybby999 what happens when nodes where those singular instances go down? You mention Azure's support for compose, yet their most useful simple service (azure container apps) is based on kubernetes. Azure itself obviously invests in kubernetes and mostly keeps compose services created a while ago alive (without investing in them).
@@DevOpsToolkit I have a singular machine running Docker Daemon, on which I spin up one instance per application in my solution. I'm using Docker to replace VM's and am using Compose to configure the deployment in a singular place... would you say Compose is out of place for that use case?
@Ybby999 you're right. In your scenario using docker compose makes sense, assuming that for one reason or another you cannot use Cloud (that you run on a self hosted server). Personally, I haven't seen that case. I've seen self hosted data centers (onprem) but they always contained many servers. When a single server is all that's needed, it makes more sense to use cloud than to have your own server (probably below a desk). If my assumption is wrong and using cloud is an option, i would recommend Azure Container Apps, Google Cloud Run, or any other similar service.
i like putting breakpoint on all services that i'm debugging '__') so all 3rd party services spawned on TestMain using ory/dockertest for other internal services spawned using goroutine then just put breakpoint anywhere you want to trace when running the test/debug
Assuming that your production is in Kubernetes, I cannot imagine a reason not to use the same manifests (with maybe a few tweaks) when developing as those used for production. So, I'm answering the question with another question. Why Docker Compose if you already have Helm chart, Kustomize, or whatever you're using in production and other permanent environments. Now, if your production is not in Kubernetes but, let's say, AWS Lambda, Google Cloud Run, Azure Container Apps, or something else, than it does make sense to use Docker Compose for local development (not if you're working remotely). The third option is that your production is defined through Docker Compose but, in that case, I think you might have a bigger issue than what you're using for development. Even Docker itself (the company) does not believe or even use Docker in production.
am still new to okteto. but waht are basically the advantage or disadavantages of using okteto instead of observability with grafana , loki and prometheus. becuase the man goal is to be able to test your application and be sure it works in production.
Okteto is a tool that helps deploying apps and synchronizing code during development while građana, Loki, and Prometheus help with collection and querying of metrics and logs typically used to observe production systems.
What I'm saying is "if you already have k8s manifests, then it's simpler to use them than maintain separate ones for dev". I am in no way saying that k8s is simpler than Docker Compose, but that Compose is not well suited for production and, if you already have production defined, why not use it for dev as well.
The video just convinced me to stick to docker compose 😂 and kubernetes for local dev? I don't think he is a regular dev, he hasn't really worked with apps having 5 minutes compile and startup time 😂 you likely don't need kubernetes for your next side project, unless you are profitable enough to afford a devops person. you can always easily switch to kubernetes when you have to...
K8s best swarm by being designed to be a base and to be extensible. As a result, almost all vendors and projects chose it over docker as their base to build additional layers and solutions. At the end, it was docker against the world, and the world won.
@@DevOpsToolkit That does not describe the difference at all. Swarm is much easier to deploy, extend and deploy onto. SRE is much easier to implement too. Where K8s wins is in its support for RBAC, but in practice, other than complicating deployment, I've never seen examples of this used to control access of multiple teams onto a single cluster as IaC deployments favour the best practice of deploying clusters per project-environment. Ive seen, ironically, more references to swarm being deployed as a shared resource, and with pull based GitOps the lack of access control isn't even a real issue. K8s uses more resources, is way more fragile and difficult to set up and requires an ongoing support team that swarm just doesn't. For all this it offers no advantages, but as its the only major orchestrator offered by major cloud vendors we all have to go along and pretend the emperor isn't naked. This is not a criticism of the video - things in production and dev should be the same - and like it or not, production is likely going to be K8s. K8s is the wrong answer we are all going to use anyway.
Any statement about k8s like "it uses more resources" really depend on which variation of k8s one is using and which components one ads on top of it. Kubernetes alone is nothing. It is only a base which already has more features than swarm but is still too rudimentary. You can, for example, use k3s and the resource usage will be lower but that still does not mean much since it depends on what you add on top of it. Swarm is NOT easier to extend. Anyone trying to extend swarm would tell you that. That's one of the main reasons why vendors did not adopt it. It does not have anything similar to CRDs. Ultimately, it does not matter any more what is better. Swarm is on life support with no one investing in it (Docker gave up on it and mirantis is keeping it on life support). If docker thought about designing swarm in a way that it can be extended by others, the situation could have been different. But, Docker's strategy was to be the only one controlling the market and, in retrospective, everyone, including Docker company, knows that was never meant to be. As a result, no one joined and even Docker (the company) gave up on it.
As a side note, I placed all my bets on Docker back in the days and used it exclusively for years. At one moment, I had to admit I was wrong and move away from it.
@@DevOpsToolkit True. The resource usage statement depends entirely on how a k8s vs a swarm is deployed. Nominally a small single purpose swarm uses at least equivalent and possibly more resources as a production ready swarm needs a minimum of 3 manager nodes for HA and then at least 2 worker nodes for the same.
What do you use for delopment and preview environments? Docker Compose or...?
Am a huge fan of compose and generally use compose for most POC like environments. Then later on, I typically end up “porting” to Kubernetes manually.
@@DiveInto I'm suggesting to invert the order. If you start with production manifests, you can use them everywhere.
@@DevOpsToolkit yep 100%, it’s great advice! Thanks buddy
cue to generate yamls, dagger, k3s (rancher/docker desktop), ingresses like admin.myproject.localhost
I use terraform
We should change our profession name from Software Engineer to Yaml Engineer
Declarative Typewriter Needed. Basic YAML knowledge needed, able to express topology into oneliners hahahahaha
But how about ysml generators like aws cdk? 🤣
YAML developers for life.
I have just watched a few mins but wow your delivery and simplicity in explaining the reasoning is so refreshing.
Even if Okteto is "simple to use" it does not remove complexity of dealing with k8s. You cannot remove complexity with handful of abstractions and simplified workflows - it's still there and sooner or later it will bite you. See "Law of Leaky Abstractions".
In larger team context I personally would rather have a lighter docker-compose workflow, but at the same time give developers ability to launch the app in minikube as well. So they at least have a chance to familiarize how production looks like and have a "sandbox".
I do agree that k8s is more complex than Docker Compose. If k8s is too much then we should not use it.
What I'm saying is different. I'm saying that if one did choose k8s, then using it in some environments and switching to Compose for others is more complex and leads to inconsistent results. If, let's say, we already have Helm charts used to deploy apps to production, isn't it easier and better to use those same charts in dev? Docker Desktop already runs Kubernetes.
As a side note, one does not need Okteto to do what Compose does. A simple `helm install` does that with the manifests that already exist. Okteto adds additional capabilities that do not exist in Compose.
P.S. I'm using Helm as an example. It could be Kustomize, ytt, or anything else used to define and deploy apps to k8s. The point is that if manifests already exist, a single command is required to run them in dev.
Nice to stumble across this video! I've evaluated most of the kubernetes development environment tools like Garden and Tilt, and Okteto has been the best fit for my team. The reverse port forwarding functionality, enabling remote PHP debugging, was one of the key differentiating features for us. So for the past few months we've been working on adopting a self-hosted Okteto solution as our development environment. Working great so far!
Would be interesting to see a comparison of Okteto, Tilt, and Skaffold (I see others have asked for it). What's in one and not in another, what do they have in common (and how do they implement it differently), and when to prefer one over the other. Based on your experience/opinion, of course. You might not be able to do such a comparison in 30 min. 🙂
It's coming as a part of a new project (series) I'll start working on in late January 2023.
I'm not yet sure whether all three of those will be there. It'll likely be Okteto, DevSpace, and Telepresence (due to reasons I cannot reveal just yet).
Viktor: "Please, don't use docker-compose, cause we have so many toys, about which I can tell you cool stories" :)
For me the main benefit of docker compose is the simple management of dev dependencies like database or message queue for which I don’t have k8s manifests as on prod I usually use managed services of some cloud provider.
Isn't it just as easy to add the db as an optional dependency in the helm chart of the app itself (the one used in production). Actually, that should be easier since you do not have to define the chart itself (assuming you're using helm in production), but only the dependency (the db).
What is the problem with using docker compose for production? (and all other environemnts?) Considering mu app has 50k MAU?
What is the reasoning behind not using docker-compose in production? I know all the extra goodies that come with k8s eg: auto scalability, better fault-tolerance and .., but not all projects have such requirements. Can you elaborate your vision on that?
Apart from "all the extra goodies", it's about the investment. If you already have it running with Docker Compose and it does what you need it to do, great. Keep it. But, if you're investing in something, you want to try to invest in something that has a future, and Docker is not it when production is concerned. Even Docker (company) itself gave up on it. Everyone is using and investing in Kubernetes. Whichever innovation or solution to a problem you might need, it's likely in Kubernetes. You need better storage? Kubernetes. Mutual TLS? Kubernetes. Progressive delivery? Kubernetes. And so on and so forth.
We all make mistakes, and it's unavoidable that the part of investments we make (time, money, etc.) will end up being a bad choice or become obsolete. However, that does not mean we should make choices based on things that are obviously a dead-end. No one is investing in Docker Compose or Docker Swarm for production. Nothing new is coming, and existing projects are not maintained (much).
All in all, if you are already using Docker Compose in production, keep it as long as it does what you need it to do. The moment that stops being the case (the moment you need to add something to it or invest more time into it), move to Kubernetes.
The same goes for Mesos and Nomad. Those are great platform as well, but they are, just as Docker, on life-support when production is concerned. Almost no one is investing in them.
Also, not all Kubernetes-based services are complicated. Far from it. Kubernetes alone is the base, not the end-user solution. Take a look at Azure Container Apps. They're easier than anything, better than Compose, users do not see Kubernetes, but it's running in Kubernetes. Or you can choose Qovery, or any other out of many solutions that provide much better results than Docker alone, that are based on Kubernetes, yet eliminate complexities of Kubernetes.
P.S. Docker itself is NOT dead. It's thriving as a developer experience tool. When I say NO to Docker, I mean NO to using Docker in production or any other permanent environment.
@@DevOpsToolkit Thank you for your detailed comment! 🙂 Fair enough, I totally agree with your points.
I would love to see a video on the combination of okteto and devspace. They seem like they compliment each other quite well.
Good idea. I'll add it to my TODO list.
Sweet thanks!!
Everytime I've tried to use a development Kubernetes system, it has broken badly all by itself at some random time, requiring it to be completely removed and reinstalled. I just want something that just works, every day. Docker compose just works.
It all depends on what you do in Kubernetes. If you reproduce what Compose is doing, there is very small chance or breaking or things going wrong. It's a Deployment with a Service resource. That's it. Compose does not have an equivalent of much more than those two.
Now, if you go full throttle on Kubernetes, you are introducing additional features that, typically, do not exist in Compose. It can be something as simple as Ingress towards more complicated stuff like progressive delivery, serverless, etc. Those are more likely to break, especially if one is not experienced with them. However, that is not directly comparable with Compose since it does not have those features.
Nevertheless, you're right. Compose works. It's simple (for today's standards) without doing much (compared to k8s), but what it does it does well. You'll have to deal with the risk of having differences between what you're using in dev and what's in production, but that's a separate discussion.
I like to use Skaffold for this purposes, compared with Okteto it lacks some functionality, but it's simpler (IMHO) to setup and use
Skaffold is great and one of the first (if not the first) of that kind.
greenfield projects should do everything possible to use open source software so all runtimes can be available in development. Then seed test data locally.
1:30 maybe mixing up staging/testing environment with developer environment 👀? The production environment is usually an artifact of the development environment. Meaning in dev we have a full stack application running with websockets for hot reloading via a node.js server but in production it’s a static website serving from the /build folder. A docker compose has node etc while the kubernetes manifests do not. If they would be the same, we would ship node.js, android studio to the cloud. Docker compose in combo with i.e. tiltdev provides a very replicateable turn key developer experience while the kubernetes manifest is providing a replicateable production environment. Spinning up a production system per pull request is totally the right approach though orthogonal to docker compose. Different use cases. Love your content ❤️
For production env, the deployment manifests are stored in a separate git repo (picked up by ArcoCD). Should we have manifests duplicated in the repo where we want to do Okteto or what is the best practice here?
Argo CD app should reference a repo with manifests and include environment specific parama. That means that the manifests themselves can be anywhere, so why not keep them where the rest of the code of the app is?
@@DevOpsToolkit well, b/c commit to the repo with code will trigger CI/CD proceeds which will produce new image which should be updated in deployment manifests which is another commit into same repo causing newer ending loop…
@lyubomyrvyhovskyy2668 you should update the image in the argo CD application manifest.
@@DevOpsToolkit ok so 2 repos: 1st source code + k8s manifests, 2nd with another manifests (kustomize) for argocd. Right? Currently, we have a single repo with all manifests for the app with 2 sub-folders: base and overrides/[env1…].
Do you have any reference project with such configuration? It would be very helpful to check how it done.
@@lyubomyrvyhovskyy2668 I thought you're using Helm (most common choice even though I don't like it). With Kustomize, that part is a bit trickier since you probably want to keep all overlays and the base in the same place. Still, I would keep it in the repo with the app code since I cannot imagine developing an application without being able to run it locally or remotely before pushing code changes to Git. So, I prefer using comments like `[skip ci]` to avoid triggering pipelines. Otherwise (if all the manifests are elsewhere), you're effectively forcing developers to figure out other ways to run their apps by rewriting k8s manifests into Docker Compose (or something similar) and facing the challenges of ephemeral environments being completely different from permanent ones. We had similar discussions in the past about build scripts, tests, and other artifacts produced (in the past) by other groups and, eventually, we did get to the point where all those are in the repos with the rest of the code of apps and not elsewhere.
Interesting. I used to use Kompose to migrate from docker compose to kubernetes manifest...
Kompose might be a good starting point. Further modifications are required, but it can be a good base for those.
Main question for me would be how easily it integrates into IDEs like VSCode. Remote Extension DevContainers using docker-compose is easy to use for developers
I never tried the integration. It's a single command that I tend to execute from the vs code terminal.
Great info, thank you for taking the time to put this together.
"you are in much bigger trouble then you think" - welcome to my past 3 years of my life.
One of the things I always do with docker compose is to create a bind mount to be able to get the local dev directory onto the container and in that case the uid of the user inside the container has to match that of my local env, curious to know how okteto handles this
Okteto synchronizes files from local dirs into containers. Like that, it works no matter whether the cluster is local (vm on a laptop) or remote.
Is there an option out there that allows me to spin up a vm with no external internet access and run my dev cluster from there ?
Any local Kubernetes spins up a VM (unless running in Linux) and is not accessible outside your cluster. It could be Docker Desktop, Minikube, or, my favorite Rancher Desktop. Now, if you're looking for a remote environment, it all depends on where your infra is. If it's on-prem, I suggest k3s (you'll still need to create a VM whichever way you're creating VMs). On the other hand, if Cloud is OK, I suggest Civo. It's fast, and it's cheap, and, I think, you can make it accessible through a VPN so that no one outside it can access it.
Hey,
First of all thanks for the video. But its just the same as devspace. Whats difference?
In that video, I did not intent to review okteto but rather to use it as an example that demonstrates that there is no need to docker compose. I'll do a comparison with devspace and a few other tools soon.
How do you make Chrome transparent?
I record screen separately from talking head. During the edit, I remove black background and overlay screen on top of the talking head.
Just dabbled here...and great video to encourage me to gradually move to okteto. Thanks
I'm not necessarily saying that everyone should move to Okteto. It's a great product/service, but the goal of that video was not that much to go deep into Okteto but, rather, to demystify the need for Docker Compose for dev and Kubernetes manifests for prod. You should check out Okteto but also note that there are other similar tools as well. Also, I hope to do a video comparing similar tools soon.
@@DevOpsToolkit Thanks. I actually develop alot with docker-compose before deploying. I will definitely explore the need to use any of the tools in dev and later in prod to simply the many things involvs.
Very cool - any reason to use okteto over DevSpace?
There are some overlaps, but also some differences in how those two tools approach the problem.
In this video, I picked a "random" tool since the idea was not to compare or pick a "winner" but rather to demonstrate that there is no need for Docker Compose.
I already added to my TODO list "compare different tools for dev environments in k8s".
Indeed, the greatest advantage of using Kubernetes from your laptop is the scalability. I deploy kubeadm clusters but I have powerful laptops and a workstation. This is even more important if you have to deal with service mesh stuff. Okteto is a great alternative.
Thank you so much Victor for your AWESOME contents🍻
TBH, Docker Compose was never built for production, it was built for local development. And we have Swarm for that.
But k8s is the way to go. Great video
Back in the days, there was ambition to use Compose (with or without Swarm) in production. Those days are long gone now and Docker's plans changed completely. I like the new direction heading towards dev experience.
Sorry, it's early to bury Swarm for now) Take a look at the "Is Docker Swarm Dead? The Future Of Docker Swarm" article.
Sorry, it's early to bury Swarm for now) Take a look at the "Is Docker Swarm Dead? The Future Of Docker Swarm" article.
Docker (the company) gave up on swarm and mirantis is mostly focused on Kubernetes. I agree that swarm is not dead. It is on life support.
Swarm hardly gets any new adopters, almost no project or vendor adopted it, and docker gave up on it. How can anyone talk about the future of swarm when almost everyone agreed that k8s is the base for almost all innovation?
Hey, there Kube nation, I'm a Kubernetes beginner and I'm wondering what are the the typical gotchas for beginners when using Kubernetes. Cheers and subscribed.
We use DevSpace and can do it on our own k8s cluster without having to use a SaaS service. Much more powerful than Okteto in our evaluations
Okteto does not have to use SaaS either. It works in any k8s cluster. As for being more or less powerful... I hope to do a comparison soon.
But if we need to mantain dockerfiles anyway, why abandon the compose "extension" in favor of a new tool in the stack, that's just an overhead
I think it's the other way around. You need Dockerfile (unless you're using Buildpacks) and you need Kubernetes manifests to deploy your app to production and other permanent environments. So, the question is why do you want to maintain docker-compose.yaml if you already have the manifests (e.g., Helm, Kustomize, etc.) that you can use to deploy your application to any environment? From that perspective, Docker Compose is a new tool that does not serve a clear purpose (apart from the historical perspective when many, including me, thought that Docker Swarm is a good choice for production). What does Compose give you that you do not have in your Kubernetes manifests?
P.S. Dockerfile is a format to define container images and is used by any engine and not only Docker which, by the way, does not even work in k8s anymore.
P.P.S. All my comments assume that production is in k8s. If that's not the case, Compose serves a purpose if you're running production elsewhere (e.g., GCR, Azure Container Apps, Lamdba, etc.) and you want to develop locally.
P.P.P.S. No one should use Docker in production. Even Docker itself (the company) is not using it for that purpose internally.
The reason to use docker compose or podman compose it's free or cheeper. . Thanks for the video.
If you're referring to it being cheaper than working in "real" servers/clusters, I agree. Still, running a Kubernetes cluster locally (it can be with Docker Desktop) is only a click away. A very small amount of CPU and memory is required to run a local k8s, especially if using something like Rancher Desktop based on k3s.
'Contact us for custom pricing', indeed. Thanks for the talk though, it was a good demo.
My use case is a little different, but I am trying to go from docker-compose to Kubernetes right now ( probably how you video go into my feed)
I am struggling with getting the cni setup for my use case. I need 200-1000 containers (or pods) all with about 100 ports exposed using the ipvlan driver (so each pod/container gets it’s own up address that is reachable by other machines on the same subnet)
Setting this up with docker-compose just worked, but I am struggling with kubernetes (probably because I’m so new). Also should probably mention that this is in non-cloud scenario
I was never in a situation to export more than one port. Whenever possible, I use Ingress and in rare occasions, I might expose a single port of a Service. So, I'm not sure whether that are some limits you might face.
I'm assuming that you specified all those ports in the Service manifest associated with the Deployment/StatefulSet. is that the case? If it is, what did you see as the side effect?
@@DevOpsToolkit Yeah, my use case isn't for a dev/prod system, it is more of an environment used for scale testing. Each pod simulates a device that our product interacts with, ideally each 'device' would have its own IP/DNS... however we can't hit the scale we want, so we settled with 100 devices per pod (thus 100 exposed ports + 22 for ssh).
The issue is that none of the Pods are not reachable outside of the k8s cluster (by their IP addresses). I looked into ingress but that doesn't seem to fit our needs (as it seems my option would be to bind container ports to the host port and only have a single IP?)
With docker the IPVlan driver was used (macvlan would also work but wasn't necessary). I think k8s supports the ipvlan driver, but I can't seem to figure out how to get it working.
Thanks for your reply, I wasn't expecting a response but yeah I'm still digging into this. I think it's possible, just hard to navigate because until this week I didn't even know what a CNI was.
Have you defined Services with NodePort? That should give you publicly accessible ports without ingress. If you use LoadBalancer Services you'd get the same plus LB but I guess that might be more challenging when on-prem.
@@DevOpsToolkit I did, I could hit the containers/ports if I was on the Node running the container, but it wasn't reachable from any other Node (or our other box). Maybe something is misconfigured? That is what I was hoping would work when I frst dug into this. (using a service to expose all the IPs/Ports)
That must be a misconfiguration. When you create a NodePort service, the port is open on all the nodes of the cluster.
Epic video Viktor, super interesting!
Thanks for the great tip. K8S are so handy.
my question is : how to do with ide : I work with pycharm and docker compose, and i had try a lot of time to move on rancher desktop, but each time, i couldn't setup my interpreter.
I'm not sure about pycharm (not working with it myself). As for Docker Compose... I abandoned it a long time ago. It's all about Kubernetes today, so I suggest embracing it sooner than later. Once you do, Compose will become a waste, and you'll adopt k8s-native tools instead.
One more thing... IDE is typically not an issue. You're still writing code in your favorite IDE. What changes it how we deploy, run tests, etc. That is now happening in k8s clusters (local or remote).
@@DevOpsToolkit I was not clear : with pycharm (jetbrain ide) you have a docker-compose integration for the interpreter. You create your dockerfile with a python service (for example a webservice + dbservice + redisservice) and you can configure pycharm to use the docker-compose file and your webservice to be the interpreter. You will have autocompletion, run, debug, navigation into the docker dependencies etc like a standard projet. For a big projet it's a must have.
I agree with you, we want to use k8s for the dev part. Now, we have to create and maintain a docker-compose file for the dev part (and it's a big compose file), and all helm charts for production part. And of course, we loose a lot of time, because some configuration into the compose file change and we forget the helm part.
I just search a solution to use k8s for the dev part, with a good integration with a good ide
sry for my english
Thx a lot for yours videos
@@fsx9991 if I understood this right, you can just work on your local files, but Okteto ensures your local folder is mounted into the container, hence changes are reflected immediately or are recompiled upon changes are detected (depending on the language).
The advantage is, that you do not need a different way to deploy services for local development. You can just use the same way you would use for production (e.g. helm charts).
I remember listening to a talk when I visited ContainerDays 2022 conference and it was really nice, though I don't think most developers are yet ready to completely give up local development and go down the Kubernetes route from the beginning.
That's correct with a small correction. It works in local k8s clusters as well.
This is fantastic. Finally!!!
Half of video with no real explanation and examples, just an advertising. Okteto != K8s and Compose is a configuration of the stack that runs locally out of the box and in swarm cluster as is. The okteto config is not shorter than compose one. It is the COPY of compose plus couple of sections. Okteto could easily use compose config as base configuration with custom extensions, but they prefer to develop their own format for their own specific platform. Increase the coupling with different solutions is not my way.
It is not an ad for okteto. I did not receive any compensation from them. They did not even know that the video will be published.
The point I'm trying to make is that I do not see any advantage of using compose if production is in k8s. Why not use prod manifests (or variations of those manifests through helm values or kustomize) in dev? So, the question is not why compose but rather why would one have something completely different in dev and prod.
I'm sorry I used docker for dev... and prod... Thank you!
I used docker (and swarm) everywhere for a couple of years.
Wow this is amazing, can you do a comparism between Okteto and Tilt?
Will do... :)
You just proclaim using Compose in production is a bad idea but then never actually back up why you think that is the case... No arguments for your position makes it look very weak imo
(EDIT) we had a very fruitful discussion below!
That's my bad. I thought it was obvious. Not even Docker (company) runs it in production. Here it goes... There is no distribution across nodes (scheduling), networking is too basic, there are limited storage options, observability is bad, there is no ecosystem nor support from providers, etc. Docker never designed Compose to be something that runs in production. Docker Swarm is the one we were supposed to use, but that one died.
@@DevOpsToolkit what if I'm just deploying to an on-prem server with singular instances of the containers? No scaling. Also, there's some useful integration of Compose in Azure Devops
@Ybby999 what happens when nodes where those singular instances go down?
You mention Azure's support for compose, yet their most useful simple service (azure container apps) is based on kubernetes. Azure itself obviously invests in kubernetes and mostly keeps compose services created a while ago alive (without investing in them).
@@DevOpsToolkit I have a singular machine running Docker Daemon, on which I spin up one instance per application in my solution. I'm using Docker to replace VM's and am using Compose to configure the deployment in a singular place... would you say Compose is out of place for that use case?
@Ybby999 you're right. In your scenario using docker compose makes sense, assuming that for one reason or another you cannot use Cloud (that you run on a self hosted server). Personally, I haven't seen that case. I've seen self hosted data centers (onprem) but they always contained many servers. When a single server is all that's needed, it makes more sense to use cloud than to have your own server (probably below a desk).
If my assumption is wrong and using cloud is an option, i would recommend Azure Container Apps, Google Cloud Run, or any other similar service.
i like putting breakpoint on all services that i'm debugging '__')
so all 3rd party services spawned on TestMain using ory/dockertest
for other internal services spawned using goroutine
then just put breakpoint anywhere you want to trace when running the test/debug
Zeet looks very good!
not very convincing.
why do you think is bad to use docker compose for prod?
Assuming that your production is in Kubernetes, I cannot imagine a reason not to use the same manifests (with maybe a few tweaks) when developing as those used for production. So, I'm answering the question with another question. Why Docker Compose if you already have Helm chart, Kustomize, or whatever you're using in production and other permanent environments. Now, if your production is not in Kubernetes but, let's say, AWS Lambda, Google Cloud Run, Azure Container Apps, or something else, than it does make sense to use Docker Compose for local development (not if you're working remotely). The third option is that your production is defined through Docker Compose but, in that case, I think you might have a bigger issue than what you're using for development. Even Docker itself (the company) does not believe or even use Docker in production.
am still new to okteto. but waht are basically the advantage or disadavantages of using okteto instead of observability with grafana , loki and prometheus. becuase the man goal is to be able to test your application and be sure it works in production.
Okteto is a tool that helps deploying apps and synchronizing code during development while građana, Loki, and Prometheus help with collection and querying of metrics and logs typically used to observe production systems.
compose is the GOAT
Constant animations saying to "Like," "Join," "Subscribe" in your video is very irritating.
That's great feedback. I'll reduce them or remove them completely from upcoming videos.
Thanks mate for the great content =)
Thanks a ton!
I think acorn might be a player in this space, but in any event please add acorn to your list. Maybe they'll sponsor a video 😊
Already started working in the material :)
ruclips.net/video/uj6Gan10Wig/видео.html
todo: description
Silly me... Fixed... Thanks for letting me know.
weird
this blow my mind
I don't think this is simpler
What I'm saying is "if you already have k8s manifests, then it's simpler to use them than maintain separate ones for dev".
I am in no way saying that k8s is simpler than Docker Compose, but that Compose is not well suited for production and, if you already have production defined, why not use it for dev as well.
Devspace for me!
Mhhhh yeah but actually no
👍
Thanks a ton
The video just convinced me to stick to docker compose 😂 and kubernetes for local dev? I don't think he is a regular dev, he hasn't really worked with apps having 5 minutes compile and startup time 😂
you likely don't need kubernetes for your next side project, unless you are profitable enough to afford a devops person.
you can always easily switch to kubernetes when you have to...
Dear lord. Kubernetes is hateful to use wether for dev or production. Do not understand how K8s beat swarm.
K8s best swarm by being designed to be a base and to be extensible. As a result, almost all vendors and projects chose it over docker as their base to build additional layers and solutions. At the end, it was docker against the world, and the world won.
@@DevOpsToolkit That does not describe the difference at all. Swarm is much easier to deploy, extend and deploy onto. SRE is much easier to implement too. Where K8s wins is in its support for RBAC, but in practice, other than complicating deployment, I've never seen examples of this used to control access of multiple teams onto a single cluster as IaC deployments favour the best practice of deploying clusters per project-environment. Ive seen, ironically, more references to swarm being deployed as a shared resource, and with pull based GitOps the lack of access control isn't even a real issue.
K8s uses more resources, is way more fragile and difficult to set up and requires an ongoing support team that swarm just doesn't. For all this it offers no advantages, but as its the only major orchestrator offered by major cloud vendors we all have to go along and pretend the emperor isn't naked.
This is not a criticism of the video - things in production and dev should be the same - and like it or not, production is likely going to be K8s.
K8s is the wrong answer we are all going to use anyway.
Any statement about k8s like "it uses more resources" really depend on which variation of k8s one is using and which components one ads on top of it. Kubernetes alone is nothing. It is only a base which already has more features than swarm but is still too rudimentary. You can, for example, use k3s and the resource usage will be lower but that still does not mean much since it depends on what you add on top of it.
Swarm is NOT easier to extend. Anyone trying to extend swarm would tell you that. That's one of the main reasons why vendors did not adopt it. It does not have anything similar to CRDs.
Ultimately, it does not matter any more what is better. Swarm is on life support with no one investing in it (Docker gave up on it and mirantis is keeping it on life support). If docker thought about designing swarm in a way that it can be extended by others, the situation could have been different. But, Docker's strategy was to be the only one controlling the market and, in retrospective, everyone, including Docker company, knows that was never meant to be. As a result, no one joined and even Docker (the company) gave up on it.
As a side note, I placed all my bets on Docker back in the days and used it exclusively for years. At one moment, I had to admit I was wrong and move away from it.
@@DevOpsToolkit True. The resource usage statement depends entirely on how a k8s vs a swarm is deployed. Nominally a small single purpose swarm uses at least equivalent and possibly more resources as a production ready swarm needs a minimum of 3 manager nodes for HA and then at least 2 worker nodes for the same.