I'm not quite sure I understand what Kool brings on top of Docker compose (which is already included within Docker binary).
Instead of specifying Kool global network as external I can specify my own whatever network. As long as it's named, it doesn't matter whether it is external or not, it will just get created by whichever app is up first and the next will join it.
Hello Andrei! - What Kool brings to the table is a take on how dockerized local dev environments should work, trying to solve common usability issues along the way. We understand Docker as a great containers management tool, while we aim to make Kool a great Local environment management tool - leveraging Docker and containers for that, of course, but making the DX (developer experience) better for dev envs.
If you have a few minutes, please take a look at this previous article where we explanined more about the ideas behind Kool.
Now back to this use case here - yes, we could use a named network whithin docker-compose.yml so it doesn't need to be external per say. Kool uses an external network, which is created/managed by Kool CLI. The main advantage of this approach is to seamlessly also share it with possible one-off containers you may wanna run (using kool docker) - as we wanna leave it for kool to handle the networks, so the developer doesn't need to worry at this moment with the nuances of Docker Compose networking, but still achieve the desired/expected behaviour. As mentioned in the article, this is something that comes out of the box with the Presets we ship.
Well, I did, but the previous article seems like the classic marketing/SEO article that provides a lot of unspecific claims. Like "It simplifies the way you use Docker in your local environment by removing the Docker "speed bumps" that slow you down" - the only benefit listed for Kool CLI, without providing examples.
Optimised images was my only meaningful takeaway, in that it's always good to have another choice. So far I've used Bitnami images as they have a long proven expertise in production optimised configs for lots of common software.
Other than that it's a lot of nice and unspecific things with respect to what exactly Kool brings on top of plain compose (beyond a little CLI sugar, though it's not clear whether it really warrants another tool that's a wrapper around a standard tool)
Thank you for your input (and time!) looking at the previous article, @andreidascalu
! This kind of feedback is especially useful for improving how we present in the future.
Your point seems to focus on Kool CLI as a simple "replacement" for Docker/Docker Compose CLI tools - with the recognized CLI sugar. It's important to take a comprehensive look at what the Kool project offers:
Custom Docker images, as you mentioned. We aim to optimize for development and production usage.
Presets - pre-configured Docker environments for popular frameworks.
Scripts - kool.yml for standardization of tasks related to dev environment paired with kool run for running them.
Kool CLI - is the tool that brings it all together, and allows us to offer more features and the desired better DX through the CLI sugar!
kool create - to get a new app environment with one command (from our presets).
kool share - to create a live URL for your local environment.
Sugar: kool start/kool stop/kool status with more fluent interfaces for what an environment is, not an inert group of containers is.
Sugar: kool exec/kool run without the need to worry about dockerTTY allocation whether running locally or in a CI environment.
It's important to make clear we don't intend to be a full replacement to docker compose by any means, we just recreate the necessary commands we find useful for a better developer experience. All the rest stays where it belongs and is always reachable - you can always keep using docker compose with an application using Kool Preset configs if you don't like the sugar!
Many developers should be familiar with the usual custom Bash scripts with helpers created for each dockerized project they have worked, and we hope - like us - they are not a big fan of that. Kool's standard UX/DX across projects we hope will be seen as valuable to others, just like it currently is to us! I can't say this enough - Docker is great for managing containers, but all the time new people realize something is missing, a gap for using it effectively for local development. We are in the missing to help with that!
Having said all this - we know we have a long road ahead, with many features to add - then perhaps at some point it could change your view as to kool CLI adoption - i.e more presets and images for different stacks (community actively working on this); kool cloud command for K8S deployment (soon); kool doctor for guaranteeing Docker environment setup is correct (soon).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not quite sure I understand what Kool brings on top of Docker compose (which is already included within Docker binary).
Instead of specifying Kool global network as external I can specify my own whatever network. As long as it's named, it doesn't matter whether it is external or not, it will just get created by whichever app is up first and the next will join it.
Hello Andrei! - What Kool brings to the table is a take on how dockerized local dev environments should work, trying to solve common usability issues along the way. We understand Docker as a great containers management tool, while we aim to make Kool a great Local environment management tool - leveraging Docker and containers for that, of course, but making the DX (developer experience) better for dev envs.
If you have a few minutes, please take a look at this previous article where we explanined more about the ideas behind Kool.
Now back to this use case here - yes, we could use a named network whithin
docker-compose.ymlso it doesn't need to be external per say. Kool uses an external network, which is created/managed by Kool CLI. The main advantage of this approach is to seamlessly also share it with possible one-off containers you may wanna run (using kool docker) - as we wanna leave it forkoolto handle the networks, so the developer doesn't need to worry at this moment with the nuances of Docker Compose networking, but still achieve the desired/expected behaviour. As mentioned in the article, this is something that comes out of the box with the Presets we ship.Well, I did, but the previous article seems like the classic marketing/SEO article that provides a lot of unspecific claims. Like "It simplifies the way you use Docker in your local environment by removing the Docker "speed bumps" that slow you down" - the only benefit listed for Kool CLI, without providing examples.
Optimised images was my only meaningful takeaway, in that it's always good to have another choice. So far I've used Bitnami images as they have a long proven expertise in production optimised configs for lots of common software.
Other than that it's a lot of nice and unspecific things with respect to what exactly Kool brings on top of plain compose (beyond a little CLI sugar, though it's not clear whether it really warrants another tool that's a wrapper around a standard tool)
Thank you for your input (and time!) looking at the previous article, @andreidascalu ! This kind of feedback is especially useful for improving how we present in the future.
Your point seems to focus on Kool CLI as a simple "replacement" for Docker/Docker Compose CLI tools - with the recognized CLI sugar. It's important to take a comprehensive look at what the Kool project offers:
dockerTTY allocation whether running locally or in a CI environment.It's important to make clear we don't intend to be a full replacement to
docker composeby any means, we just recreate the necessary commands we find useful for a better developer experience. All the rest stays where it belongs and is always reachable - you can always keep usingdocker composewith an application using Kool Preset configs if you don't like the sugar!Many developers should be familiar with the usual custom Bash scripts with helpers created for each dockerized project they have worked, and we hope - like us - they are not a big fan of that. Kool's standard UX/DX across projects we hope will be seen as valuable to others, just like it currently is to us! I can't say this enough - Docker is great for managing containers, but all the time new people realize something is missing, a gap for using it effectively for local development. We are in the missing to help with that!
Having said all this - we know we have a long road ahead, with many features to add - then perhaps at some point it could change your view as to
koolCLI adoption - i.e more presets and images for different stacks (community actively working on this);kool cloudcommand for K8S deployment (soon);kool doctorfor guaranteeing Docker environment setup is correct (soon).