31–40 of 144 posts
Earlier quoted context omitted.
There's minikube. There's been minikube for a long while.
Is there an easy way to build an image locally and start it in minikube without an external registry or running a local one?
https://kubernetes.io/docs/getting-started-guides/minikube/#...
Earlier quoted context omitted.
There's minikube. There's been minikube for a long while.
Is there an easy way to build an image locally and start it in minikube without an external registry or running a local one?
Earlier quoted context omitted.
If "Docker == containers" continues to hold true in many people's minds, then it's possible that Docker Swarm could feel like the "vanilla" orchestration platform. Of course those of us familiar with the platforms know better, but that mindset could persist, especially with pseudo-technical decision-makers.
Could you elaborate what alternatives to docker are worth checking out? I'm unfamiliar with containers and out of my head I can't name anything besides docker.
Earlier quoted context omitted.
There's minikube. There's been minikube for a long while.
Is there an easy way to build an image locally and start it in minikube without an external registry or running a local one?
another approach would be to run docker inside a k8s-pod (docker-in-docker), that way you can run images without having to push them to a registry but still test it in k8s-environment (at least to some extent).
Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)
Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.
Looking at moving to k8s but that was my reason for swarm at the time. And it was the right one as it just worked with minimal effort.
Earlier quoted context omitted.
But the thing is that as a developer, it doesn't matter what you start with - you have both and you're using compose files, etc. So Docker is trying to make the orchestrator less relevant now, and says that 'don't worry about the orchestrator'. You, as a developer, are using Docker and Compose. (Or at least that's what Docker is trying to do here, I think.)
I don't think having support for multiple orchestrators is valuable except as a transitional thing. In this case, presumably, transitioning from Swarm to K8S. Nobody is gonna want the hassle of supporting both outside a transition.
In general enterprises don't like to be told "throw away your existing system to adopt my platform".
I see them stating "...for developers using Windows and macOS" but not mentioning Linux. I feel like I'm missing something in how I'm reading that page. How can I make use of this on Linux?
That separation is already in place for Windows and Mac, so we're starting there.
Kubectl was already providing docker cli commands like "exec" "logs" etc. So you can execute some of these commands on a k8 cluster with the docker binary too? And why would you do that?
All I see is struggling for relevance, duplication of functionality and a very unnecessary vendor lock-in vector.
This really helps with the dev-to-production story for containers. When people first started using Docker containers, we were promised things would run identically in dev and production - no more "but it worked on my laptop" issues. Then the rise of orchestrators meant that there again became a significant difference between running an app locally (in compose) and in production (on Kubernetes). Docker for Mac/Windows…
There's minikube. There's been minikube for a long while.
This really helps with the dev-to-production story for containers. When people first started using Docker containers, we were promised things would run identically in dev and production - no more "but it worked on my laptop" issues. Then the rise of orchestrators meant that there again became a significant difference between running an app locally (in compose) and in production (on Kubernetes). Docker for Mac/Windows…
There's minikube. There's been minikube for a long while.