81–90 of 169 posts
Earlier quoted context omitted.
No, because the purpose of Docker is not 'to run XCode CLI tools'...
I think the GP means that the purpose of Docker is to provide containers, which are a substitute for VMs. If you are going to be running a VM anyway, why run a container?
I normally used minikube for openfaas development - I appreciate the efforts of the project, it's an invalueable tool. The DfM integration works very well for local development and I've got some screenshots below: https://twitter.com/alexellisuk/status/949595379326210048 Make sure you do a context-switch for kubectl too. I see some people talking about Swarm vs Kubernetes. Swarm has always maintained a less modular a…
While the two solutions are obviously with different goals in mind, one being to fully run the kubernetes setup locally, and the other one to run a few docker containers who talk to one another, if it's for the purpose of running a simple-ish dev environment, in my experience, docker-compose is much faster and simpler than minikube.
Earlier quoted context omitted.
Minor nitpick, it's called macOS now.
I don't understand why people refer to pre-Sierra releases as macOS. Sierra and onwards is called macOS. guillaumerose was referring to all versions, so both "all OS X versions" and "all macOS versions" would be wrong, no...?
For example, Wikipedia[1] has a page called "OS X Yosemite" which describes it as "A version of the macOS operating system", and the Wikipedia article on macOS[2] says it was first released in 2001.
So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments. I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud pr…
"Kubernetes on the other hand is trivial with GKE." Yes, true, but that's apple vs oranges. Swarm doesn't compete against GKE, it competes against Kubeadm. Because sometimes one actually can't or won't use cloud services.
Earlier quoted context omitted.
No. Docker for mac runs a Linux VM.
Doesn't that defeat the purpose of Docker? But anyway, thanks for the info :)
* Docker is useful for production and has various other benefits, and Docker for Mac is a nice way to develop locally with Docker even if it's not as efficient as on Linux.
* Docker for Mac uses some built-in virtualization tools in macOS to share network and filesystem more efficiently than you could do with the older VirtualBox approach. So it's maybe a little closer to native OS support than you're thinking.
* A typical configuration has a single Linux VM holding many Docker containers, which is better than the alternative of many VMs.
Earlier quoted context omitted.
Thanks for the reply. I agree with what you say. I'm not tying to say people should all jump to k8s. Having options on the market is great. But I was trying to refute the notion that Kubernetes has no advantages unless you're running a huge cluster. My main points where: * It works great with 1 node. * It comes with many features that Swarm does not have that are useful even at 1 node (PersistentVolumes, StatefulSets…
I appreciate where you’re coming from, but you can’t bring GKE into a conversation about the challenges of Kubernetes ops. GKE does everything for you.
Earlier quoted context omitted.
Helm makes this easy. It’s great, just use the templating features and not the package management stuff.
We found the same thing after the package management stuff caused issues in prod. We rolled our own go program that just does go tpl substitution in yaml with overrides like helm. Works on charts out of the box, but instead of talking to a service, it outputs a yaml manifest ready to kubectl apply. We've thought about open sourcing it. It took us literally a day to put together and had worked without flaw for 8 month…
* Render the chart and run it through kube-cloud-build[1] to make sure my containers are all built before I deploy: `helm template /path/to/chart | kube-cloud-build -r repo`
* Deploy with helm: `helm upgrade RELEASE_NAME /path/to/chart`
Has been working really well for me.
So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments. I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud pr…
So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments. I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud pr…
Have any recommended resources for learning Kubernetes? I've looked at it a few times, but it always seemed rather intimidating.
Earlier quoted context omitted.
Doesn't that defeat the purpose of Docker? But anyway, thanks for the info :)
Running a Linux VM on Mac defeats some of the purpose of Docker, but it's still valuable: * Docker is useful for production and has various other benefits, and Docker for Mac is a nice way to develop locally with Docker even if it's not as efficient as on Linux. * Docker for Mac uses some built-in virtualization tools in macOS to share network and filesystem more efficiently than you could do with the older VirtualBo…
I assumed the main idea of Docker were reproducible builds on different machines and wanted to use it for building iOS apps.