9 ms·

Ask HN: Alternatives to Vagrant for development environments?

135 points by purephase 9y ago

I'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. The number of issues we'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. We love Hashicorp and, I don't mean this to be a slight against them, but I'm curious what alternatives people are using to: - Automate building dev environments (Linux-based) with dependencies etc. - Ensure that your development environment is similar enough to production to reduce/eliminate potential issues moving to production. I have done some googling around, but it still appears that Vagrant is the top dog in this space. Willing to accept that it'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. Bonus points for tools that can be re-purposed for automating deployment as well (Terraform). Parity between development and other environments is important.

phamilton 9y ago
docker compose works well for us. We pull down all our prod docker images and can get a local cluster running with one command.
scaryclam 9y ago
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.
bound008 9y ago
Docker
sebringj 9y ago
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 9y ago
  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.
hullsean 9y ago
As others have said docker. Faster, more lightweight. ‍️
- nunez 9y ago
  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 9y ago
    Why would it be a terrible option for those cases?
    - sethammons 9y ago
      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.
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
jldugger 9y ago
> deprecations with legacy Chef setups test kitchen supports a lot of various platforms, including vagrant, AWS, and openstack.
- krakensden 9y ago
  Test kitchen isn't really a substitute, it doesn't do the plumbing (ports, random folders) you want for a dev environment.
  - akulbe 9y ago
    Doesn't test kitchen just call vagrant by default?
jonaf 9y ago
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.
labdsf 9y ago
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/
berdario 9y ago
Nix https://jakob.gillich.me/post/2016-03-22-self-contained-development-environments-using-nix/ https://jakob.gillich.me/post/2016-03-22-self-contained-deve... https://ariya.io/2016/06/isolated-development-environment-using-nix https://ariya.io/2016/06/isolated-development-environment-us... You can easily automate provisioning and deployment with Nixops: http://container-solutions.com/step-towards-future-configuration-infrastructure-management-nix/ http://container-solutions.com/step-towards-future-configura... 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-with-nix_15.html http://lethalman.blogspot.co.uk/2016/04/cheap-docker-images-...
- BuuQu9hu 9y ago
  Nix changes the game.
- atmosx 9y ago
  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 9y ago
    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?
sumedh 9y ago
I guess most people would just say Docker. Personally after using docker, I just cannot go back to Vagrant.
oomkiller 9y ago
minikube
lobster_johnson 9y ago
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 9y ago
  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.
  - cygned 9y ago
    Using Docker for Clojure and JavaScript development here. I actually don't have these issues. There is a performance loss, sure, but not nearly as much as you describe it.
    - ledgerdev 9y ago
      I would say just check out the threads for the sort of experiences people are reporting across pretty much every stack from rails to symphony. In my case above it was actually jvm clojure building an uberjar, probably worst case scenario. REPL was usable because it didn't do a any mounted volume access, just network access.
Necromant2005 9y ago
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 9y ago
  Just so people don't get confused. Hashicorp is the company behind Vagrant, but they are not affiliated with Docker.
jitl 9y ago
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 9y ago
  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!
  - jitl 9y ago
    We still support a local Virtualbox/Vagrant VM for the "offline" case, but that's the very environment that we're actively migrating away from. Realistically speaking the thought of an "offline" environment is impossible - our users need regular updates of our repositories, which requires a network connection; and of course SO/Google is a necessity :-). Also, at our scale we're running into the limits of Apple's machines. There's just not enough RAM for all of (Jetbrains Something), (Local VM with tons of services), (some ARM emulator), (40 Chrome tabs), (Slack). We can't provide a good local dev experience going forward. Between MiFi and MOSH (a UDP, mobile optimized SSH "alternative"), I think we can support the transit use case without using a local VM.
roadbeats 9y ago
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 9y ago
  OP specified "development environment is similar enough to production", and you recommended "Linux setup based on Arch Linux and Xmonad". Does not compute.
SteveNuts 9y ago
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.
mastazi 9y ago
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 9y ago
  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 9y ago
    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".
andreareina 9y ago
What issues are you having?
nickstefan12 9y ago
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.
acejam 9y ago
Docker compose with locally mounted volumes.
- sawantuday 9y ago
  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
aub3bhat 9y ago
Docker compose its unbelievably good.
alrs 9y ago
Vagrant is a symptom of MacOS. Move to Linux, and you get native containers for free.
- BozeWolf 9y ago
  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 9y ago
    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.
    - BozeWolf 9y ago
      Just open an ask hn for it;-) I will vote it up!
    - aaronbasssett 9y ago
      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.
im_down_w_otp 9y ago
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.
mitchellh 9y ago
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!
- russell_h 9y ago
  First off, thanks for your work on Vagrant. I've had my frustrations with it, but over the years it has been an invaluable tool. That brings me to this: I wish I could pay for Vagrant - not just the VMWare Fusion plugin, but a fully supported configuration of your choosing. I would happily migrate our dev environment to that configuration, and spend spend several hundred dollars per user per year year on Vagrant if I thought it would work more reliably as a result.
- arekkas 9y ago
  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 9y ago
    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.
- 9y ago
pinoyyid 9y ago
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.
meddlepal 9y ago
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/
rpcope1 9y ago
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 9y ago
  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 9y ago
    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).
segmondy 9y ago
LXC, build with ansible or your favorite server config.
nik1aa5 9y ago
Terraform by Hashicorp? Once development is over, you can easily deploy your infrastructure.
user5994461 9y ago
- 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.
corford 9y ago
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).
nickjj 9y ago
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
rcarmo 9y ago
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 9y ago
  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'.
joemaller1 9y ago
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.
itamarst 9y ago
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.
gtirloni 9y ago
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 9y ago
  Did you try Vagrant with VMWare Workstation?
  - purephase 9y ago
    We're using it with Fusion and, I believe, it's a big part of the issues we're experiencing. We have both Virtualbox and Fusion users that have the same issues.
  - gtirloni 9y ago
    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.
- stephenr 9y ago
  There is also a Vagrant plugin for Veertu, which is based on Hypervisor.Framework, and it's free too. Unfortunately, it doesn't seem to be fully baked yet, I haven't had much success trying to use it, and there may not be many public base boxes available for it, as tools like Packer don't support it yet. Edit: Another option on macOS is Parallels. You need the "Pro" or "Business" licence to use with Vagrant, but it works reasonably well for my needs.
frik 9y ago
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.
PaulHoule 9y ago
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.
choxi 9y ago
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.
_jezell_ 9y ago
Minikube
TylerJewell 9y ago
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).
deleted 9y ago
[deleted]