7 ms·

Is there a reason you don't just use https://rancherdesktop.io/ https://rancherdesktop.io/

ksbrooksjr 4y ago
Vagrant has a few advantages compared to Rancher (and Lima[1] which I believe Rancher uses under the hood). Because of its popularity, there are so many open source Ruby provisioning scripts you can use as a reference when provisioning your own VMs. You can also package up a provisioned VM as what they call a "box" that can be shared with other developers. It also natively integrates with tools like Ansible, Chef, and Puppet which make it a lot easier to manage the provisioning process. And finally, many of the books and tutorials I've read use Vagrant, so it's much easier to follow along if you have Vagrant installed. For example I was recently reading the book Ansible for Devops by Jeff Geerling, and Vagrant and Virtualbox were used pretty extensively throughout the book. Also, if you decide to package VMs to use in production it's pretty easy to integrate with Packer, which is another Hashicorp product. [1] https://github.com/lima-vm/lima https://github.com/lima-vm/lima
- jamescostian 4y ago
  Docker is extremely popular and so there are plenty of reference Dockerfiles. Books and tutorials on K8S, Packer, ECS, GKR, etc all use OCI images, so docker (or something similar) is useful to have on hand. Yes, packer supports vagrant too, but just go to their website and go to guides, and notice how many docker guides they have and how prominent they are compared to vagrant. I think it's not about the individual implementations but about the paradigms they work in Let's say I have a bug in prod. I just adjust my code, or Dockerfile, or some declarative config (say cloudformation or k8s definitions) and push it, and the CD doesn't say "go to existing machines and update them", it says "spin up containers with this new build and configuration, divert traffic to them, and then remove the old containers when safe". For me, provisioning is not something I want to touch outside of setting rules for autoscaling and saying "start using this new build". So arguments about provisioning (for my usecases) don't help - they sound like adding more responsibility onto me that computers already handle for me. I don't feel that this declarative and abstract model is necessarily ALWAYS better than the imperative model you get with ansible et al. And I can think of an example: if you just need to run 1 command everywhere, ansible (or chef or puppet) is much faster than pushing a commit and waiting for the build and deployment. Or maybe if you needed a custom kernel. But I've never had an instance where those things were valuable or valuable enough; in all my experiences, fine-grain provisioning and treating servers like pets instead of cattle has never been a better choice (especially given bursty traffic), so I'm trying to broaden my horizons and understand where it would be a better choice.
  - ksbrooksjr 4y ago
    I definitely get where you're coming from, but I think developers tend to overestimate the complexity of managing servers, and underestimate the complexity of managing a Kubernetes cluster. The last time I looked into Kubernetes even the most minimal setups required 500MB of memory on each machine, and that's assuming you're using a lightweight implementation like k3s or k0s. If you're using a managed service like EKS or GKE you're going to require even more memory and cpu resources. Kubernetes is ostensibly supposed to help you autoscale, but you only end up needing to autoscale because of the memory and cpu that Kubernetes is itself consuming. Most webapps can scrape by with just a single vm. Hacker News itself runs on a single machine [1]. Also if you reserve a vm for long term usage most cloud providers will give you a pretty steep discount [2]. If you need the ability to burst during periods of high traffic, you can just use a burstable instance, which all of the three big cloud providers support (i.e. Azure, GCP, and AWS). I used to think managing servers introduced unnecessary complexity until I tried it, and realized it's really not as difficult as I thought. With kernel live-patching and unattended upgrades, I never have to manually update anything. Blue-green deployment is as simple as rsyncing files to the server, starting the updated app on a different port, and then updating your reverse proxy's config to point to the new version of the app. Any decent reverse proxy like Caddy or Nginx will support zero downtime config updates. You don't have to build containers, store them in a registry, or update any yaml manifests. Kubernetes manifests have gotten so complex that developers are inventing programming languages like Jsonett and Dhall to generate configuration files. Also, the skills you learn from managing servers are incredibly portable. Some of the Unix skills that I've gained from playing around with EC2 instances have actually helped me manage my personal Mac (which is of course a member of the BSD family of Unix operating systems). When you learn Cloudformation those skills don't even translate to other cloud providers. The skills that you learn from managing a server are also incredibly stable and stand the test of time. Bash is older than Docker, the programming language (Golang) that Docker was written in, and likely many of the developers using it. [1] https://news.ycombinator.com/item?id=16076041 https://news.ycombinator.com/item?id=16076041 [2] https://instances.vantage.sh/?cost_duration=monthly https://instances.vantage.sh/?cost_duration=monthly

Vagrant has a few advantages compared to Rancher (and Lima[1] which I believe Rancher uses under the hood). Because of its popularity, there are so many open source Ruby provisioning scripts you can use as a reference when provisioning your own VMs. You can also package up a provisioned VM as what they call a "box" that can be shared with other developers. It also natively integrates with tools like Ansible, Chef, and Puppet which make it a lot easier to manage the provisioning process. And finally, many of the books and tutorials I've read use Vagrant, so it's much easier to follow along if you have Vagrant installed. For example I was recently reading the book Ansible for Devops by Jeff Geerling, and Vagrant and Virtualbox were used pretty extensively throughout the book. Also, if you decide to package VMs to use in production it's pretty easy to integrate with Packer, which is another Hashicorp product. [1] https://github.com/lima-vm/lima https://github.com/lima-vm/lima

jamescostian 4y ago
Docker is extremely popular and so there are plenty of reference Dockerfiles. Books and tutorials on K8S, Packer, ECS, GKR, etc all use OCI images, so docker (or something similar) is useful to have on hand. Yes, packer supports vagrant too, but just go to their website and go to guides, and notice how many docker guides they have and how prominent they are compared to vagrant. I think it's not about the individual implementations but about the paradigms they work in Let's say I have a bug in prod. I just adjust my code, or Dockerfile, or some declarative config (say cloudformation or k8s definitions) and push it, and the CD doesn't say "go to existing machines and update them", it says "spin up containers with this new build and configuration, divert traffic to them, and then remove the old containers when safe". For me, provisioning is not something I want to touch outside of setting rules for autoscaling and saying "start using this new build". So arguments about provisioning (for my usecases) don't help - they sound like adding more responsibility onto me that computers already handle for me. I don't feel that this declarative and abstract model is necessarily ALWAYS better than the imperative model you get with ansible et al. And I can think of an example: if you just need to run 1 command everywhere, ansible (or chef or puppet) is much faster than pushing a commit and waiting for the build and deployment. Or maybe if you needed a custom kernel. But I've never had an instance where those things were valuable or valuable enough; in all my experiences, fine-grain provisioning and treating servers like pets instead of cattle has never been a better choice (especially given bursty traffic), so I'm trying to broaden my horizons and understand where it would be a better choice.
- ksbrooksjr 4y ago
  I definitely get where you're coming from, but I think developers tend to overestimate the complexity of managing servers, and underestimate the complexity of managing a Kubernetes cluster. The last time I looked into Kubernetes even the most minimal setups required 500MB of memory on each machine, and that's assuming you're using a lightweight implementation like k3s or k0s. If you're using a managed service like EKS or GKE you're going to require even more memory and cpu resources. Kubernetes is ostensibly supposed to help you autoscale, but you only end up needing to autoscale because of the memory and cpu that Kubernetes is itself consuming. Most webapps can scrape by with just a single vm. Hacker News itself runs on a single machine [1]. Also if you reserve a vm for long term usage most cloud providers will give you a pretty steep discount [2]. If you need the ability to burst during periods of high traffic, you can just use a burstable instance, which all of the three big cloud providers support (i.e. Azure, GCP, and AWS). I used to think managing servers introduced unnecessary complexity until I tried it, and realized it's really not as difficult as I thought. With kernel live-patching and unattended upgrades, I never have to manually update anything. Blue-green deployment is as simple as rsyncing files to the server, starting the updated app on a different port, and then updating your reverse proxy's config to point to the new version of the app. Any decent reverse proxy like Caddy or Nginx will support zero downtime config updates. You don't have to build containers, store them in a registry, or update any yaml manifests. Kubernetes manifests have gotten so complex that developers are inventing programming languages like Jsonett and Dhall to generate configuration files. Also, the skills you learn from managing servers are incredibly portable. Some of the Unix skills that I've gained from playing around with EC2 instances have actually helped me manage my personal Mac (which is of course a member of the BSD family of Unix operating systems). When you learn Cloudformation those skills don't even translate to other cloud providers. The skills that you learn from managing a server are also incredibly stable and stand the test of time. Bash is older than Docker, the programming language (Golang) that Docker was written in, and likely many of the developers using it. [1] https://news.ycombinator.com/item?id=16076041 https://news.ycombinator.com/item?id=16076041 [2] https://instances.vantage.sh/?cost_duration=monthly https://instances.vantage.sh/?cost_duration=monthly