
Ask HN: Alternatives to Vagrant for development environments? - purephase
I&#x27;ve been using Vagrant for about 5-6 years now to automate the setup of development environments. It was a great tool for spinning up environments that were similar to production and easily shared across team resources that jump in and out of projects.<p>The number of issues we&#x27;re dealing with daily with Vagrant is rising. The productivity boost it provided is entirely gone and the support is taking a substantial amount of time.<p>We love Hashicorp and, I don&#x27;t mean this to be a slight against them, but I&#x27;m curious what alternatives people are using to:<p>- Automate building dev environments (Linux-based) with dependencies etc.
- Ensure that your development environment is similar enough to production to reduce&#x2F;eliminate potential issues moving to production.<p>I have done some googling around, but it still appears that Vagrant is the top dog in this space. Willing to accept that it&#x27;s us and not the tool, but issues with NFS sharing, port collisions, support for Fusion, deprecations with legacy Chef setups and more is just more than we can handle right now.<p>Bonus points for tools that can be re-purposed for automating deployment as well (Terraform). Parity between development and other environments is important.
======
mitchellh
As the creator of Vagrant, I just wanted to say thank you for using the
software. 5-6 years is no joke! I'm glad/hopeful that the project had a net
positive impact for you during that time. :)

I won't attempt to hijack this thread or use it for personal motives to
convince you to stick with it. I understand technologies change, requirements
change, and choices change. The only thing I ask is if you can find the time
to email me (mitchell@hashicorp.com) with your pain points so we can look to
see how we can improve things in the future.

And the only other comment I'll make is that at HashiCorp we have full time
staff on Vagrant and have continued to drill down issue counts through the
year. So if you are a Vagrant user: fear not, it is something we continue to
deeply care about.

Thank you!

~~~
arekkas
we switched to a docker environment and the benefits are immense, starting
from bootstrap to boot time. Docker-compose makes it easy to pull 3rd party
deps that just work, instead of configuring them in one VM. Of course docker
has it's downsides, but maybe vagrant could incorporate docker and start
moving away from the one-VM principle?

~~~
brianwawok
Seems docker compose is the slightly better way to go.

I don't docker for my actual code , but it's handy for the local DB and redis
type problems.

Actual language changes best way I think. Java and Python I tend to just run
from jetbra ins with docker having all the dependencies up.

------
berdario
Nix

[https://jakob.gillich.me/post/2016-03-22-self-contained-
deve...](https://jakob.gillich.me/post/2016-03-22-self-contained-development-
environments-using-nix/)

[https://ariya.io/2016/06/isolated-development-environment-
us...](https://ariya.io/2016/06/isolated-development-environment-using-nix)

You can easily automate provisioning and deployment with Nixops:

[http://container-solutions.com/step-towards-future-
configura...](http://container-solutions.com/step-towards-future-
configuration-infrastructure-management-nix/)

But if you need to share/deploy what you worked on, in some place where you
might not have Nix available, you can just as easily create Docker containers
out of your Nix expression:

[http://lethalman.blogspot.co.uk/2016/04/cheap-docker-
images-...](http://lethalman.blogspot.co.uk/2016/04/cheap-docker-images-with-
nix_15.html)

~~~
atmosx
HM, I use Vagrant daily to switch among Linux distros and run tests. Nix has a
steep learning curve and although the community seems to be great, it is small
and getting help might be problematic.

Enforcing NixOS to a team in my view will lead to a severe productivity
downturn in the short-medium run.

Nix is much older than people think, I am not it will be around in 5-10 years
though. I believe that Ansible, Puppet, Chef, etc are way simpler and more
valuable market-wise if you are not into Haskell already...

~~~
bluejekyll
I don't know about that. The concepts of Nix answer significant deficiencies
in the tools you mention. Those tools all assume that you need to build and
operate systems, which seems like a lot of effort and overly complex, when the
trend is to make all systems throwaway.

I've been following Nix for a while, and don't yet have an arena where I can
play with it, but the concept is exactly what I think the industry needs. The
biggest challenge that I see with nix is that it is basically a new OS and
will require a while before many people are comfortable adopting it.

Also, it's not Haskell, it's got it's own minimal functional language, Nix,
right?

------
lobster_johnson
While I agree that Vagrant isn't 100%, the biggest source of our issues with
Vagrant have actually been with VMware Fusion. VMware has lots of issues with
managing its state. 8.x has a long-standing issue with port forwarding rules
getting stuck, so some of us downgraded to 7.x just to get productive again.

The whole reason we migrated to VMware, about 3 years ago, was that we were
using Virtualbox and being really bothered by the issues with it, things like
corruption of files accessed through the shared folder mounts, that weren't
being addressed. It's exasperating how brittle this VM stuff is.

Personally, I'd love a slimmer Linux-only solution based on Xhyve or Apple's
Hypervisor.framework. I don't really want a Vagrantfile, I just want a low-
level tool that I can drive from a wrapper, which we need anyway. Both Docker
for Mac and Minikube now uses Xhyve, with great results.

We're slowly migrating our stack over to Kubernetes. Building with Docker for
Mac is great, and Minikube seems really promising.

~~~
ledgerdev
As far as I know, docker for mac isn't actually usable for dev work if you use
mounted volumes. Basically it pegs CPU and makes disk access 10-150 times
slower than native which makes mounted volumes impossibly slow. A personal
example would be building a jar on a macbook native took 11 seconds, takes
docker for mac 9 minutes. See [https://github.com/docker/for-
mac/issues/77](https://github.com/docker/for-mac/issues/77)
[https://github.com/docker/for-mac/issues/668](https://github.com/docker/for-
mac/issues/668) and a slew of other reports that can all be traced back
mounted volume performance.

Moral of the story I moved to linux.

~~~
silentOpen
Many developer use cases do not demand heavy bind mount file access. For
example, incremental builds of static languages typically work fine.

docker/for-mac#77 is related to "bind mount" performance but docker/for-
mac#668 is virtual block device performance. Have you posted a reproduction
workload that demonstrates the performance problems you are having?

Docker 17.04 includes a `cached` bind mount flag that relaxes consistency of
the mount in exchange for significantly reducing guest-host roundtrips
especially for inefficient workloads that repeatedly access the same files.

~~~
edsrzf
Could you please link to some docs for the cached flag you mentioned? I can't
find anything about it.

~~~
yallop
Documentation for 'cached' is on its way. There'll be a blog post up soon with
a friendly introduction, and some representative benchmarks. In the meantime
there's a drier but more detailed specification of the behaviour of 'cached'
waiting in a pull request here:

    
    
      https://github.com/yallop/docker.github.io/blob/d9a57867/docker-for-mac/osxfs-caching.md

------
jonaf
Nix has a tool called nix-ops that will provision vms on virtual box (you can
use containers powered by libvirt as well if you want). It's cool because you
can use functional programming concepts and it takes a lot of the support
headache away. The option to provision vms is really nice in some cases, which
Docker just doesn't give you. But you can also use containers, just like
docker, with reproducible builds, which means you can effectively test
deployments without ever spending a dime on real hardware.

------
rpcope1
If you're just developing against Linux, I've been using LXC 1.0 for a while
now for quickly spinning up and destroying dev environments, and I think it
works really well. LXD (which is essentially LXC 2.0 + goodies) is also great,
and makes a lot of that easier and adds features (including a lot stuff that
makes things like orchestration significantly easier), but it has a little
less documentation right now.

I think LXC has some really excellent advantages of both being super easy to
create/destroy quickly (and containers being very easy on resources), while at
the same time running a full system in the container with an init and
everything (as opposed to Docker where it's typically just one application).
The command line tools are pretty simple and straightforward (at least for LXC
1.0), and I find it a lot less fuss than using VMWare or VirtualBox in a
similar role.

~~~
throw2016
LXC best mimics a VM environment so its a nearly seamless transition for VM
workloads and setups. I have noticed a lot of people are catching on and using
LXC more and more now compared to a couple of years ago where there was
massive confusion about containers.

The biggest difference is Docker does not run the init in the container, LXC
does so it behaves more like a lightweight VM. LXC also has proper support for
standard networking and storage in the container. It's self contained.

~~~
rpcope1
Yeah, I totally agree. Speaking of networking, I really love the plug and play
nature of LXC/LXD around networking, which has enabled me to do a lot of
interesting things in conjunction with virtual Ethernet bridges and veth
devices along with OpenVPN and netem for latency simulation. In particular I
was able to simulate a really big network of devices (on their own private
"LAN") across a few simple desktop PCs, by attaching each container to one or
more bridges and then on the host joining the bridges across systems using
OpenVPN TAP devices. I was able to simulate a full blown network and test some
attack scenarios and better understand some of the network dynamics.

This isn't something that's a huge use-case applicable everywhere, but man the
flexibility is super super handy, and I haven't seen many tools out there
provide the same amount of possibilities LXC does (like all of the a la carte
cgroups functionality).

------
mastazi
For us, the biggest problem is that Vagrant, on Windows machines, doesn't run
well on Hyper-V (it has network limitations e.g. you can't force a static IP
for the machine).

So we have to keep using VirtualBox which is slower.

Another consequence of this is that in order to use VirtualBox you need to
completely disable Hyper-V, so on Windows machines our devs are forced to use
Docker Toolbox (instead of Docker for Windows which is faster but based on
Hyper-V).

(Note: we are a small team with little experience both in Docker and Vagrant
so we welcome suggestions: if you thing we're doing something wrong please
leave a comment).

~~~
extrapickles
As others have mentioned, use Docker Compose instead of vagrant. That way you
don't have the overhead of learning two different systems (compose and the
Docker command line are very similar).

If it takes more than 20m to get a new dev machine setup from a fresh OS, you
probably haven't pushed enough of your environment into images.

Don't be afraid to ignore the rules about what and how much goes into a
container as those are for production images (eg: customer facing). It's
prefectly fine for this usecase to treat it more as a mini-vm than the
'process on steroids' you use for production.

~~~
cryptarch
I'm currently using docker-compose for work on a SaaS product written in Java,
it's quite a joy to work with.

I am struggling with slow image builds, but that's more of a problem of "not
having a build server", "not having a Docker registry set up" and "using a lot
of 3rd party online build dependencies".

------
corford
I seem to be the minority in this thread but am happy with the flexibility,
maturity & reliability of Vagrant. The trick has been sticking to virtualbox,
off-loading all provisioning work to ansible as early as possible and using
dual nics on the vms so you don't have to worry about port collisions for the
most part.

Setup: Win10 host and 6 vagrant guests (mix of internally produced jessie and
xenial64 boxes with Packer). Terraform on AWS infra in staging & production
with ansible for config/provisioning and Consul for node discovery.

[Edit] some tips to make dev work pleasant on Win10: Use cmder, mRemoteNg and
configure samba to expose your git working dir back to the host (so file
change hot reloading works reliably if you want to do your coding on the host
with something like VSCode or Sublime).

------
labdsf
Looks like you may want to try Vagga [1]. It is Linux-only, but you said that
you want Linux-based environments. It is for development environments by
design, so it is way easier to setup than Vagrant. Even if it does not solve
your problems (which you have not specified), at least you will spend less
time maintaining it.

[1] [https://vagga.readthedocs.io/](https://vagga.readthedocs.io/)

------
gtirloni
There are very valid reasons for why Docker moved away from VirtualBox and I
think the same applies to Vagrant.

I wish Vagrant would work on bringing xhyve, Hyper-V and KVM to the same level
of support as VirtualBox.

VirtualBox is the biggest source of issues in our Vagrant environment and
there is no indication that's going to change.

~~~
0x4a42
Did you try Vagrant with VMWare Workstation?

~~~
gtirloni
Yes. I have a license for it and the Vagrant plugin but the experience is not
great. Too many rough edges that I couldn't pitch that idea to the rest of the
team.

VMware would be ideal since it works on all three platforms we care about and
has great performance, even with the added costs.

------
jitl
We've had the same experience with Vagrant. Vagrant is a very general tool
that makes it easy to do some fairly complex things, but that generality adds
significant overhead. I counted THREE different SSH connection systems in
Vagrant the last time I was trying to optimize it.

We eventually wrote our own tool that duplicates the smallest possible Vagrant
featureset.

We use SSH for control, Unison for real-time file syncing, and Chef for
"provisioning" configuration of the remote developer environment. Our tool
requires only SSH access to some host -- so we provision an EC2 instance for
every engineer, and then connect it to our tool; but we could use local Docker
or even a Vagrant-managed VM. We reimplemented Chef Solo provisioning, with
100% backwards compatibility with our existing Vagrant Chef recipes, which was
really easy! We leverage SSH's ControlMaster for persistent connections.

Our tool does the same things that we were using Vagrant for, but takes 1/3 of
the time for typical tasks. Where Vagrant would take ~6 minutes to provision a
host, our tool takes ~2 minutes using the exact same Chef recipes. We managed
to shave a full 30 seconds of mystery time off between when `vagrant
provision` would start, and when Chef would begin it's run.

I encourage you to think about cloud developer environments in general. We got
big wins in dev productivity by moving our devenvs off engineer laptops.

~~~
praneshp
Do you have any engineers that take public transportation every day? My
current company has a dedicated team to maintain a developer VM that runs on
our Macs, and that has made my life much better. I don't need internet access
to write and test code (except to google/SO, of course). I can also afford to
take the slow train (Caltrain is twice as slow if you take the slowest one).

If your commuting employee size is low, I guess it's not important enough
problem to solve. I (and a few others here) would love to see a blog (or repo)
showing off your tool!

~~~
adrianN
Is it normal to start working before you arrive at the office? Does the
commute count to your working hours? If I were to commute by public transport,
I wouldn't work for my employer during that time, I'd do something that I
enjoy, read a book or work on my own projects.

~~~
praneshp
I like to have the choice. Sometimes my wife and I try to cook something
complex for breakfast, and I take the train 1.5 hours later, which also goes
about 25 mins slower. I replace my usual book reading with work, so I can
leave around the same time I usually leave in the evening. I also work all the
way on the commute home, so I leave early enough to help cook/climb and still
be in bed at 10.

Also, I enjoy what I do at work, and love the company I work at. I don't
really care about where I do that work from, or if I worked 2 hours (a week)
over my working hours. Actually I make it a point to read code from other
parts of the company over the weekend because I find that more useful than
pointless side projects.

------
scaryclam
Can you elaborate on any of these issues? I've been using vagrant for a
similar amount of time and don't find that there are really that many problems
with it, nevermind to find a daily increase with them. There are certainly
alternatives, but if you're having issues with vagrant to the extent that that
your question implies, then you're likely to have have issues with those as
well.

------
pinoyyid
I run all of my production services in simple *nix chroots. It's fairly simple
to rsync these onto my dev machines to get the hi-fi local versions for
testing. The only proviso is that you use similar environments, so in my case
Ubuntu, for both production and development.

------
hullsean
As others have said docker. Faster, more lightweight. ‍️

~~~
nunez
and also a terrible option for non 12 factor apps (i.e. anything with hard
dependencies on the underlying system or other apps, which many do)

~~~
lenlorijn
Why would it be a terrible option for those cases?

~~~
sethammons
In our case, we had difficulty with docker due to logging to syslog in
addition to stdout and stderr. We have shared volumes and persistent data on
disk, and we have test cases where we kill child or parent processes, but if
the parent process was pid 1, the container would die. We've addressed all of
that in different ways and develop in docker with docker compose. The biggest
pain now is that sometimes containers stop being able to reach one another,
requiring a restart of docker for mac, and, for some reason, each time we up a
container, it requires internet and VPN access to check for the latest images
and will just hang without it, making offline development practically
impossible for code that needs to run in docker. That limits what I can work
on when on the train.

------
nickjj
I moved to Docker about 2.5 years ago and haven't looked back since.

It's just really nice to be able to build code on my dev box and have it run
in production or any other machine without any fuss. It even has tools to help
you scale to multiple hosts. Really, it's a complete tool set to take you from
development to production.

If you're interested I launched a Docker learning platform[0] last week. It
happens to contain a 5 hour course that will take you from "What is Docker?"
all the way to "I'm super comfortable using Docker / Docker Compose on my own
projects".

You can watch the first 20 videos for free. The free videos cover topics like
understanding what Docker is, how it works, and getting it installed.

[0] [https://diveintodocker.com/courses/dive-into-
docker](https://diveintodocker.com/courses/dive-into-docker)

------
alrs
Vagrant is a symptom of MacOS. Move to Linux, and you get native containers
for free.

~~~
BozeWolf
And after moving to linux start an "Ask HN" topic "what tools can replace
macos tools on linux".

Your comment would be: "not having all the tools available is a symptom of
using linux as a desktop os".

~~~
hatsix
I get that this is a troll comment, and I shouldn't feed it... but seriously,
what tools does macos have that linux doesn't? (I type this on a macbook pro)
I have to add a ton of things to OS X in order to get it to behave in a sane
manner... utilities to manage windows, utilities to re-enable the volume keys
when I connect to an external display, utilities to enable alt-tab-like
behavior, a utility to take screenshots that have sortable timestamps -- so
the latest screenshot is always at the top, homebrew, which lets me install
software, GCC... the list goes on... that's not even development-specific
utilities.

All of the development-specific tools are cross-platform. I have yet to use a
tool that isn't available on Linux, and our entire development staff are
running OSX full-time.

~~~
aaronbasssett
Sketch, Keynote, Paw

I'm a developer, but I also talk at community groups and conferences. I know
there are alternatives (Inkscape, Impress, Postman) but they're all missing
one or more features I use frequently, or are just not as polished.

That being said I'll probably make the change to Linux for my many development
machine at some point and keep an Air or something lightweight as a
conference/presentation machine.

~~~
yupyup
Please don't take this the wrong way but the most important thing in a
presentation should not be the graphical aspect of the slides, it should be
the content, specifically how you can communicate with the audience with what
you're saying verbally.

I have seen awesome talks and it didn't matter if the slides were not pretty.

~~~
cagataygurturk
I recommend you to take a presentation training from domain experts (mainly
physchologists) and you'll understand how wrong you are.

~~~
brianwawok
Experts that think ever meeting needs a PowerPoint? No thanks.

A Google doc outline and some demo is enough for most dev presos.

~~~
cagataygurturk
Well, like you know how to tell your problem to computers, those experts know
how to tell your problem to human beings. And higher you are in your career,
more you have to speak non-tech people that pays your salary and needs to be
convinced about your next idea.

~~~
khazhou
Yes but effective communication is NOT about visuals or font choice. An idea
presented clearly and concisely is key.

------
sumedh
I guess most people would just say Docker. Personally after using docker, I
just cannot go back to Vagrant.

------
meddlepal
Open source project plug!

How about considering a change in paradigm? Instead of trying to spin
everything up locally you instead have a shared development environment and
bridge to it from your local laptop or desktop. Consider a large microservices
environment with twenty or hundreds of services and the need to develop not
only against those services but ones your coworkers are working on as well.
Telepresence ([http://telepresence.io](http://telepresence.io)) allows you to
develop locally on your laptop and expose a process locally that can talk to
Kubernetes resources in a remote cluster and vice versa.

Check it out: [http://www.telepresence.io/](http://www.telepresence.io/)

------
TylerJewell
You may want to consider cloud IDEs. Eclipse Che
([http://www.eclipse.org/che](http://www.eclipse.org/che)) is focused on "dev-
moding" production runtimes defined by Dockerfiles or Docker compose. There is
a Chefile capability that is similar to Vagrantfiles for creating a custom
cloud IDE on the command line from a file defined in a git repo.

Che's only dependency is Docker. It uses Docker engine to both launch its
infrastructure and to create developer environments. There will be a version
of Che that runs on Kubernetes released shortly.

Note (I am project lead for Che).

------
im_down_w_otp
We're recreating the functionality of the "Vagrantfile" through Behave (python
cucumber framework) scenarios calling down into the step definitions to
provision things through libvirt.

It unifies both the development environment setup and the system integration
testing setup/execution into the same set of tools. It's also helpful in
setting up esoteric environments through QEMU like QNX on ARM during much of
the testing before extending it to getting real hardware in the loop.

We also use the Ansible Python API to keep from having to re-implement a bunch
of orchestration primitives from scratch.

------
joemaller1
I've been using Vagrant successfully for several years, since shortly after it
launched. It's dramatically improved the dev workflow for myself and my
company.

The worst time I had with Vagrant was due to an authentication bug in v1.8.5.
That was compounded by the previous release (1.8.4) being incompatible with
the latest VirtualBox (5.1). Hashicorp was slow to release the fix, and we had
to tell users to downgrade both tools. That sucked. This was late summer 2016.

It's been smooth since then, and I haven't had to think much about the VM
aspect of our tooling in 6 months.

------
roadbeats
You can try Happy Hacking Linux with a custom post-install.sh;
[http://kodfabrik.com/happy-hacking-linux](http://kodfabrik.com/happy-hacking-
linux)

It'll get you a very productive and fast Linux setup based on Arch Linux and
Xmonad, letting you automate the setup process by auto-linking your dotfiles
and running post-install.sh if exists. This way you can spin up development
environments really fast. For example, I turned an old desktop computer to a
ready-to-use development machine in 30 minutes :)

~~~
subsection1h
OP specified "development environment is similar enough to production", and
you recommended "Linux setup based on Arch Linux and Xmonad". Does not
compute.

------
choxi
I'm working on a minimalist "cloud IDE" for machine learning projects, so you
essentially code on EC2 instances. If it looks interesting feel free to reach
out:

[http://www.haikuapp.io/](http://www.haikuapp.io/)

It doesn't have any editor features though, it probably only makes sense for
vim/emacs/etc. users. Docker is also pretty nice, but if you're not using it
in production it might not solve your problem.

------
nickstefan12
we don't run docker in production, but docker-compose has been awesome for our
local dev environment. We can get new engineers new computers going in 20
minutes!

Much easier than vagrant or running everything manually.

------
aub3bhat
Docker compose its unbelievably good.

------
SteveNuts
We've moved to an automated build system of using Packer to make pre-
configured boxes for vagrant actually. It works well, and a lot faster than
running the provisioners on a blank box.

------
rcarmo
Docker compose user here. Moved from a relatively lightweight Vagrant + LXC
setup
([https://taoofmac.com/space/HOWTO/Vagrant](https://taoofmac.com/space/HOWTO/Vagrant))
to compose around 2 years ago, and never looked back.

I have been playing around with minikube for a couple of weeks, but the added
ceremony of using Kubernetes isn't quite worth it yet for my pet projects, so
it's mostly to keep up to date.

~~~
fredsir
The power of minikube definitely comes from being able to use the same k8s
manifests for production and development. We use helm which allows us to
simply change a few settings in the production manifest so it fits development
better. To install the otherwise production made manifests (called charts in
helm speak) into minikube is simply 'helm install chart -f
chart/dev.values.yaml'.

------
user5994461
\- Automate building dev environments (Linux-based) with dependencies

automate all setup with ansible and scripts

\- Automate building dev environments (Linux-based) with dependencies

Use CI to build automatically artifacts. Provide tools for developers to ship
their app to servers.

Ultimately, delete the development environment, it's always a hassle and it's
always differing from prod. Only use prod machines.

By that, I mean that you give prod machines to devs who needs them, plus
tooling to deploy anything they want anywhere, on any of their machines.

------
itamarst
Another alternative is to have realistic staging environment and proxy normal
local process into it. Gives you local development and all the (runtime)
dependencies you need. I've built something like that for Kubernetes
([http://telepresence.io](http://telepresence.io)) but it could be extended
beyond Kubernetes, or you can build your own.

------
acejam
Docker compose with locally mounted volumes.

~~~
sawantuday
Recently found this[1] docker compose based alternative to XAMPP or WAMP/LAMP
installation. Seems pretty good alternative to quickly setup local
environments plus can be replicated in production if you are happy with
docker. As many machines/containers can be started as needed and data can be
easily shared from local file system. Raync based one liners can be setup as
well for data sync across machines.

[1]
[https://github.com/cytopia/devilbox/blob/master/README.md](https://github.com/cytopia/devilbox/blob/master/README.md)

------
sebringj
If you mount to a local folder using docker-compose up, its so simple and
quick for programming. Vagrant seems heavy compared to that and I develop on
vagrant frequently. I have a mac and have the latest docker for mac installed.
Very easy.

~~~
webo
There are other tools your team need as well: git, nvm, rvm, awscli,
terraform, kubectl, etc. Vagrant helps with pre-installing all of that,
whereas docker is mostly for running specific containers.

~~~
Terr_
Well, why not put those in docker too? The container you develop locally with
doesn't have to be the same one that eventually ends up in production.

Here's a little demo designed for editing+testing a PHP library even if your
local machine doesn't have anything more than Bash, Docker, and a text editor.

[https://github.com/DHager/docker-php-library-
demo](https://github.com/DHager/docker-php-library-demo)

------
segmondy
LXC, build with ansible or your favorite server config.

------
phamilton
docker compose works well for us. We pull down all our prod docker images and
can get a local cluster running with one command.

------
jldugger
> deprecations with legacy Chef setups

test kitchen supports a lot of various platforms, including vagrant, AWS, and
openstack.

~~~
krakensden
Test kitchen isn't really a substitute, it doesn't do the plumbing (ports,
random folders) you want for a dev environment.

~~~
akulbe
Doesn't test kitchen just call vagrant by default?

------
PaulHoule
I have no love for hashicorp: it has an ill-conceived product line starting
with the existence of vagrant and packer as separate products.

I wrote a Java program that composes a shell script that gets passed into the
user data of a cloud instance. That script sets up a Dev or production system
and builds a machine image if that is what you want. Then it sends a message
to a queue when it is all said and done.

------
nik1aa5
Terraform by Hashicorp? Once development is over, you can easily deploy your
infrastructure.

------
Necromant2005
Docker is the best option! After Hashicorp released a well working mac and
windows version [https://www.docker.com/community-
edition#/download](https://www.docker.com/community-edition#/download)

~~~
samangan
Just so people don't get confused. Hashicorp is the company behind Vagrant,
but they are not affiliated with Docker.

------
andreareina
What issues are you having?

------
bound008
Docker

------
_jezell_
Minikube

------
oomkiller
minikube

------
frik
I would favour a tool that has a DSL with C-syntax and requires no environment
dependencies.

Go lang seems like a good fit to build such a tool (for no dependencies, just
drop a singe binary). Or a Ansible alternative with a C-like-syntax.

