Do NOT Use Docker Compose! Develop In Kubernetes (With Okteto)

I do not want kubernetes for developing too complicated I like Docker compose and I have no intention to switch to something else well if that's what you're saying that's just silly [Music] developers love Docker in general and specifically Docker compose it is simple it is easy to use and it works today however I will show you that using kubernetes for development or preview environment is just as simple as Docker compose now you might ask hey if it's just as simple and not simpler then why would we move away from Docker compose well there are quite a few reasons I will not go through all of them but only mention two that in my opinion matter the most to begin with your permanent environments like for example production are running in kubernetes or most likely are running in kubernetes you might be using something else like cerebral Islam or this or that but you're most likely not running Docker only in kubernetes if that's not the case if you are actually using Docker compose in production you're in much bigger trouble than you think now everyone knows that the best option is to ship the development environment the same as production however that is often unrealistic production is bigger you might be running two or three or five or ten or hundreds of replicas in production you do not want that in your development environment also you might have a service mesh logging monitoring and quite a few other tools in production which are not needed in development environments or you might want them but there is a limit to the complexity you're willing to manage and the amount of resources you can spare nevertheless the fact that development environment cannot or shouldn't be exactly the same as production does not mean that it should not be as close to it as possible or practical if your production is in kubernetes your development environment based on Docker managed by Docker compose is too far apart you want it to be closer you want both of them to be kubernetes or both of them to be the same as production now they would not be such a big deal you know being too far apart like Docker compose for development and kubernetes for production if that is the price to pay for Simplicity however that is not the case as I will demonstrate soon using kubernetes for development environments is just as simple as Docker compose the second point I would like to state is that managing Docker compose manifests is an additional and unnecessary burden if your permanent environments are in kubernetes you already have kubernetes manifests those might be Pure yaml or Helm charts or customize or any of the other tools and formats that are available it does not really matter what the format is what does matter is that the manifests are there waiting for you to use them you just need something on top of them to make them as simple to use as Docker compose as a matter of fact not only that it will be a as simple as it can get but we'll also discover a few additional features that you cannot get with Docker compose or if you can that work better what follows is a demonstration named not to be a review like what they normally do but rather to demystify the need for Docker compose I will use octeto as a missing link and you should keep in mind that there are other tools that might that you might want to consider anyways without further Ado let's see octet to in action so that we can decide whether it is time to retire Docker compose wait stop let me tell you about this video's sponsor zit Zid simplifies quite a few things it helps with deployment in management of our applications package that's container images or serverless or Helm charts or application templates it allows us to easily run databases like MySQL postgres mongodb and redis and on top of that it has native infrastructures code framework support through terraform cloud formation or pollumi so if you need help with running your applications and managing your applications and underlying infrastructure you should check out it and not only because it's helpful but also because by checking them out you would be helping this Channel now let's go back to the video so let's get going let's see how we can use octeto there's a missing piece that will enable us to use our kubernetes clusters and kubernetes manifests and add something on top of them so that we can have simple and effective development processes environments and so on and so forth I will start by executing octeter context and over here I can select which context I would like octeto to use I will use octeto cloud but it could be any kubernetes cluster that is currently available in your Cube config configuration in this case not in this case it can be a local kubernetes cluster remote kubernetes cluster and so on and so forth but for Simplicity I'll use octeto cloud at least in this demo now the only thing that I need to do to have a fully configured everything I need for as a development environment is to say octeto up then it will work for a while working working uh let me fast forward but before I do let me say that uh there are a couple of things you should do first of all subscribe to our Channel like the video do all the stuff that you do normally with videos and second thing you should do is uh what yes you should know that there is a link to the G speed all the commands that I'm executing so you can reproduce what I'm doing so let's go back to the output of octet drop which finish by now and there are a couple of things that happened first of all it tried to build the application in my case it didn't have to build a new image because I already tried this before the image is already built but in normal situation it would build a new container image then it deployed the Manifest just as you would deploy the Manifest to a kubernetes cluster for production let's say or staging it exposed a couple of endpoints https endpoints and and I will go back to how I can configure and get that something and finally and this is very important it created it replaced the Pod the deployment of the application with the new container that is not the container that I would deploy to production but in my case be it the content that contains go compiler so that I can work and compile my application as I work oh and there is one more thing probably the most important it synchronize the files on the local file system into that new container so that whatever I write on my computer is automatically over there the source code in my case is in that container and I can prove that that's the case and that's true by listing all the files in that container remember the container is containing only by default the go compiler and if I do ls-1 I can see my Docker file and the chart and go more than go zoom and so on and so forth so all my source code is now inside that Contender which represents my development environment together with the rest of the kubernetes manifests so let me run the application and pretend that I'm developing right now by executing go run dot meaning run whatever is in the current directory now this will take a couple of moments because the first time it needs to download all the files all the libraries normally I would Mount another volume and I will show later how so that those libraries are immediately inside of that container instead of downloading them but today I was lazy so I did not set them up and it takes a couple of moments there we go there we go and yeah my application is up and running and I can see that that's the case by the last message that says hey I'm listening and serving on HTTP 8080 port and if I open my application in browser let me do that there we go it says what do you think of octeto now I already said that the files from my local file system are synchronized into that container and have that proof and that's happening all the time whenever I change something and I will prove that that's the case by opening a new terminal and run editing the file root dot go and I will replace the message with can it replace Docker compose save the file and then re-run my application by executing go run dot I should have probably installed some kind of a voucher to make sure that my files are my application is recompiled automatically I didn't do that search for Watchers depending on your language and and by the way if you're not using if you're using a language that doesn't need compilation then that refresh would happen automatically like node.js for example or HTML or python or any other language that does not compile but in my case I need to compile again and I will do that by executing go run Dot and if I go back to the browser and refresh the screen I can see the message can it replace Docker compose so my files are constantly synchronized between my laptop my computer and the development environment which in this case is enough data Cloud but it could be in any kubernetes cluster now let me stop that and exit the dev environment and take a look at octeto yaml what I want to show is how simple or complicated it is to configure architecture to do those and many other things and if we take a look at the ammo there are three major sections the first one is the build section that says hey for this application silly demo and I could have moved Publications you can you should build an image based on the current context and the image will be octet Dev slash silly demo so I'm using octetus baked in Contender image repository the second section is how we deploy the application I'm just saying hey do Cube cattle apply with whatever is in the directory case because that's where all the manifests of my application are I could have multiple entries in deploy I could have deployed the the database or multiple applications whatever I need and finally there is the dev section that says Hey whenever you develop that development should be based on the image column when the container starts it should go into the shell into bash the work directory slash SRC I want to synchronize the current directory with the SRC director inside of the container the environment will be my user and I want to port forward the port 8080. so that's all there is in this example we could use some additional definitions we could extend this but in a nutshell it's as easy as that this is as short or even shorter than or and simpler easier than Docker compose considering that I already have my application defined as kubernetes Manifest I just need to say how it should be built the container image or images how to deploy by executing your cattle or Helm or whatever you're using and finally how to define my development environment the same definition in Docker compose would be equally complex or more complex or bigger and Docker compose out of the box wouldn't be able to do this anyway because the equivalent of Docker composer only build and deploy sections the dev section is completely new it's something that Docker compose cannot even do at least not out of the box now let me destroy my development environment let's say that I finished developing and I don't want to waste resources I can just say of that to destroy and everything is poof con no more now there are a couple of additional things that you might find interesting one is to that we can launch that we can have different ways to launch at the environmental development environment and I can demonstrate that by going to cloud.com and then by clicking the launch Dev environment and over there you can see that we can create a Dev environment using the CLI just as what I did here are the instructions or we could create based on a GitHub repository or any git repository and finally from a catalog of services the one you will use most of the time if you choose to use octeto is based on the octet for CLI or at least that's what I'm using most of the time I rarely go here or never almost and by the way octeto can work with Docker compose as well on top of Docker compose instead of kubernetes manifest but don't don't do that please please please and this is actually mesh message to octet folks please remove or at least don't make it so prominent Docker composing your documentation I do not care about making development environment completely different from production I want them the same so I'm really interested only in the doctor's ability to create the development environment in kubernetes not and I repeat not with Docker compose similarly we could build and deploy applications separately do not do that either do not do that the real value for Pepto is in creating and managing development environments there are better ways to deploy seriously to a permanent environment there are better ways to build this is good for development environments and it's actually fantastic the rest of commands are just there ignore them and finally if I go to previous section of the web UI we can see the attacking create preview environments what does that mean that means that a new environment will be created for every pool request first in a given git repository following certain rules so I could have an environment without even executing anything whenever I create a pull request which is absolutely absolutely awesome and very very simple I will not go through it right now because this is not review of octeto I just want to show that we can and we should replace Docker compose with kubernetes-based environments so that they are very similar and octeto is one of the good candidates to do that this video was not is not a review of octet and you should not think that that is the only option as a matter of fact I could have used tilt or scaffold or one of the many other tools that are available and If you're not familiar with built and scaffold there are the videos check them out however today it was octeto's turn to shine so I used it again not as a review not because I wanted to show you all the features of octeto but because I want to demystify that idea that Docker compose is great for development even though we are running production in kubernetes it's not it's not simpler it's not easier and it's not better it's just completely different what you would run in one environment or the other now let's go back to Docker compose itself you saw octet in action there is no considerable investment you already have kubernetes manifest in one format or another since you have to have them to run production and other the permanent environments all you're missing is a few lines you know peptoyama and there we go all of a sudden we have development environment that is continuously synchronized with whatever we are writing with our code and it's as close to production as possible and that is the reason why we should develop in kubernetes instead of Docker compose it's just as easy and it's close to production we are getting this implicitive Docker compose your development environments are as close to what you have in production and you're getting additional features like code synchronization preview environments and so on and so forth and now comes the question for you is there a reason to continue using Docker compose if there is I really honestly really want to know what that is please let me know in the comments see you next time cheers foreign

Channel: DevOps Toolkit

Views: 34,323

Keywords: devops, devops toolkit, review, tutorial, viktor farcic, k8s, gitops, ci, cd, kubernetes, development environment, dev environment, development environment in kubernetes, kubernetes development environment, k8s development environment, dev environment in kubernetes, kubernetes dev environment, k8s dev environment, okteto, docker, docker compose

Id: RTo9Pvo_yiY

Length: 17min 32sec (1052 seconds)

Published: Mon Oct 31 2022