Using Docker containers in local development environments has become commonplace for web development. And yet, when you get down to it, using Docke...
For further actions, you may consider blocking this person and/or reporting abuse
Recently, I also decided to set up dev containers for an open source project I lead. In my opinion things are still a little rough around the edges, but definitely worth investing time into it.
You can check out some of my lessons learned here
Nice article, thanks for sharing! Indeed things are not as smooth when it comes down to efficiently using Docker containers as development environments... that is precisly our motivation!
Using Docker is awesome, but we felt there's a gap of knowledge on how to use it for local development envs in an efficient manner - several common and recurring problems people face - which should benefit from this abstraction layer that Kool stands to be. Stefan Nastic's comment and article refers exactly to that (in a comment above).
I use to say that Docker is a tool for managing containers... and Kool is a tool to help you manage Docker containers for development environments! Basically helping you look at it more from an application development standpoint, than simply learning and mastering containers, the technology itselt. This should help bring even more people to adopt and leverage it rather sooner than if they didn't have this abstraction layer.
However, I totally get your feeling when faced with such abstraction to something you probably already knows proficiently... and one of the main values we defend is to balance abstraction to ease in adoption of any team and team member with less/no experience with Docker... while maintening everything excplitly and open source there, right in your project, ready for tweaking/customization by the DevOps/Docker experts in the team! We hope we can make senior DevOps to see that... what do you think about this point of view?
Not to mention that adopting standards by itself, to have a streamlined DX (developer experience) amongst different apps/frameworks, we believe will save time and help teams be more productive - just like it has helped us for the last couple of years. Less hassle with environments, more time to focus on the app itselt.
Hey Fabricio, nice work! I've read the documentation but I still miss a point: Kool is designed to provide an easy-to-use dev environment based on Docker, but how does it work for deployment on production? Do i have to rewrite the Dockerfiles / docker-compose for that?
This is indeed something our documentation lacks currently. About production deployment there are couple of ways we can look at it -
We are testing and soon will be made publicly available the
kool cloud deploycommands, which basically will look into translating your localdocker-compose.ymlto a Kubernetes deployment - leveraging our already open source Helm charts. We hope to build some sort of service around it too.What we have done in the past and we see people doing somewhat often, althoug it's not the optimal usage, is adapting the
docker-compose.ymlfile extending it to production (addrestart, change the image to a production optimized one if suitable, and even add resources control/change port mapping accordingly). This solution already helps a lot of folks that will be running the same env they do for development, to production, making easier to manage both at the same time. But there are problems of course, observability/scaling, putting it all togheter still needs manual steps. That is why we will be focusing and releasing the Kubernetes deploy option I mentioned above soon, to be the "go to" solution for deployment.Other options like AWS ECS, are options we certianly wanna help people with too.
So our goal is, while focusing on the option number 1 to enable the community and companies leverage Kubernetes today, going really "cloud native", we certainly want to document and offer help with the other two options. Our documention is a big Work in Progress and we will soon be covering these options. As well as the
Dockerfilecreation, which is needed in all of the options above.The initial good response we are having with this post will make us run faster with all of this. In case someone wanna join and help feel free to join our Slack to discuss/get help or get a PR up on Github!
I've recently been using Microsoft's containers for local dev in vscode... How does this compare?
Hello @deranjer ! I am not sure I understand exactly what you meant by
Microsoft's containers- but I assume you are using Remote Containers on VS Code, on Windows - is that it?Kool is a set of resources around the CLI tool
koolwhich aims to replacedocker/docker-composeCLI usage, to make it easier leveraging them. As for such "resources" I mean helper scripts (onkool.yml),docker-compose.ymlpreconfigured files and customized Docker images - all tweaked for local development needs.You can get a better sense on the DX (developer experience) we are looking to offer by checking this Laravel environment read or any other of ours current presets.
By Microsoft's containers I mean this: github.com/microsoft/vscode-dev-co...
It is a list of containers that Microsoft provides for Remote Containers with an already setup dev environment based on what language/task you want to do.
Thank you for the Laravel environment read, that does clear it up significantly. Looks like kool allows for a little bit more customization. Currently MS vscode containers already provide a base image that can't be modified and comes with specific version of software already installed. I use bash scripts to modify it as needed for my specific project, but kool would perhaps offer more flexibility.
Totally! Kool might allow you to drop the bash scripts and replace it with a more flexible development environment. Join the Kool slack to find out more kool.dev/slack :)
I checked out the source for the php containers and it addresses a bunch of things I had to workaround. I will definitely be using Kool now!
Don't build the wheel repeatedly. The wheels are more than enough.
Docker itself is sufficient, additional packaging will only hide too much detail, which is not conducive to developers to understand the nature of the problem, and add additional problems.
In the short term it may improve development, CI/CD efficiency, but in the long term it is not conducive to developer knowledge growth.
Exception: unless it is a more advanced solution with better algorithms that greatly improve performance in terms of time and space.
Thanks for your insight, it's indeed a valid point...
But other point is this kind of solution also helps you learning all these, having sane defaults and learning curve, so it's easier for new comers to start using and feeling the benefits of it.
This is kind of the same tradeoff of using frameworks or not, etc.
IMHO you never should fully rely on the tool but also learn from it, how it solves the problems.