7 ms·

Atlas by Hashicorp

189 points by danielsiders 12y ago

jzelinskie 12y ago
There have been some cool tools coming out of Hashicorp, but I haven't read any experiences with people using their "full stack". Does anybody want to give their own anecdote or maybe have a link to related article?
- throwaway8978 12y ago
  They're not quite complete yet. I wish this was made more clear. Terraform has several bugs, some of them that will try and destroy perfectly good infrastructure for no reason (though it will warn you first). That said, their work is always good, it's just not complete yet, but it's branded as if it is.
- tonglil 12y ago
  - Vagrant is a given, wonderful. - Packer is for syncing VirtualBox, AWS AMIs, and what not for quick and stable starting points, also wonderful. - Consul is great for monitoring and running a services oriented architecture, haven't pushed it to its full potential though. - Serf: n/a, haven't tried yet. - Terraform: n/a. We are still using Ansible as the provisioner. Overall, good ecosystem, would recommend.
  - jimmcslim 12y ago
    Consul is built on top of Serf (the protocol at least), so given you are already using Consul, Serf wouldn't add anything for you.
  - Gigablah 12y ago
    We've been using Terraform extensively for our production deployment (a typical AWS setup with public/private subnets, load balancers, autoscaling groups, the works), and it works for the most part. There's still a hefty amount of bugs and many things will not function the way you expect, though usually you can work around them. Also the configuration language (HCL) is rough around the edges and the variable interpolation gotchas can be very frustrating.
  - porker 12y ago
    > - Vagrant is a given, wonderful. It's really useful, but on my MBP I've found using it abysmally slow (VirtualBox backend, website code shared using NFS, DB and everything else stored in VirtualBox VM and not shared folders) - page load times taking upwards of 20s (sometimes even a minute) when running direct on my MBP would be under 0.3s. Never figured out the issue, in spite of extensive research and tweaking. Replace VirtualBox with VMWare Fusion? But without a trial available of the Vagrant addon, bit of an expensive gamble.
    - jesseendahl 12y ago
      Apparently syncing file changes between the VM and host via rsync leads to a lot better performance than using NFS. Worth a shot at least: https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-rsync.html https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-r... http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-shared-folder http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-a...
    - kcorbitt 12y ago
      I have the same Vagrant setup you do (nfs-shared app directory, everything else inside the vagrant box), and while I see overheads of 1.5-2x, I've never seen anything like the 60x overheads you're describing here. Something seems off in your configuration. Perhaps you're memory-limited and the vagrant box is thrashing your swap file every time you make a request?
    - steveax 12y ago
      My personal experience is that the VMware provider is much snappier - and more stable too. The provider is what, $80 US? Not sure I'd call that an expensive gamble b
    - tszming 12y ago
      try SMB instead of NFS
- witten 12y ago
  Haven't used their full stack, but their "support" leaves a lot to be desired.
  - mitchellh 12y ago
    Our support has been strained and historically been slow, but for the past couple months, our average support time has dropped down to less than a day! We recognized the issue there and hopefully you'll have a much better experience from here on out. "Bad support" is not the company we want to be. Sorry for the poor experience you had.
    - throwaway8978 12y ago
      I got no response when asking about when a bug that was fixed in an upstream library might lead to a new binary being released. It'd at least be nice to hear "I have no idea, we're busy."
dang 12y ago
A related TechCrunch story: https://news.ycombinator.com/item?id=8727842 https://news.ycombinator.com/item?id=8727842. We're probably going to build a way to group related stories more explicitly, but manually posted comments will have to do for now.
- simonebrunozzi 12y ago
  +1!
- kolev 12y ago
  Maybe we should establish a linking convention so that these can be converted later more easily. For example, <url> #related.
  - deleted 12y ago
    [deleted]
- applecore 12y ago
  That's an interesting idea, but I hope it's pretty low on the to-do list, since posting a comment with additional links already works well. (A comment can be posted by anyone, voted up or down, or submitted as a separate item.)
joesmo 12y ago
Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs to save time. I would never use it or any tech built on top of it in development, let alone production.
- malandrew 12y ago
  They really need to rewrite it in go. Ruby has been a disaster for this particular project. Don't even get me started on the Nokogiri issues. Everything they've written in go has functioned better IMHO.
  - FooBarWidget 12y ago
    Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
    - sciurus 12y ago
      Even if you use their all-in-one package, you can still have dependency problems installing vagrant plugins. https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/4278 https://github.com/mitchellh/vagrant/issues/4278
      - FooBarWidget 12y ago
        Yeah but those are plugins, the Vagrant author can't do anything about what third parties do. You mentioned Go as a better language, but Go does not solve that problem it does not support loadable modules at all. If Vagrant were written in Go it wouldn't have supported plugins at all.
    - dandandan 12y ago
      It was much more stable for me when I was installing it through rubygems and managing our middleware's dependencies with bundler directly. We've switched to the embedded ruby and it's a struggle but we deal with it since it's probably MUCH less work to support now that it's standardized across all vagrant installs.
wallflower 12y ago
Great job, Hashicorp! Exciting to see the shift from clunky, heavy-weight versioned Chef cookbooks/Puppet modules that attempt to prevent 'server drift' by walking the directed graph for all dependencies with server convergence to true service registries like Consul and build images. Amazon CloudFormation is pretty clunky when it comes to updating user data in the CF stack template that is passed to the resources. Sometimes it even thinks you didn't update anything. Having the file-based template update itself via consul-template seems like a more sane approach. I am curious how the 'Maintain' part of the autoscaling works given that Amazon AWS has pretty crude autoscaling mechanisms available if you use only what CloudWatch offers. Hoping that 'Maintain' can be given a set of inputs on server health/application responsiveness and decide whether to scale up or scale down. Also, integration with some kind of historical/real-time cost engine would be a great feature to figure out future/past billing for cloud services.
eaurouge 12y ago
Any plans to support other providers, like DigitalOcean for instance?
- mitchellh 12y ago
  Many, many more providers are along the way. The providers already exist in the open source so its just a matter of enabling them one at a time in Atlas. But we have some surprises planned for some of them as well. :)
deleted 12y ago
[deleted]
keithchambers 12y ago
We use Vagrant, Packer, and Consul with multiple SaaS products here at Cisco. We love the Hashicorp product family and team!
akurilin 12y ago
Looks very interesting! Would be great to get an idea of what a typical workflow with this paradigm would look like.
- ujangsopian 12y ago
  a lot of useful information on this website thanks a lot yes http://obatpenyakitsesaknafas.com/ http://obatpenyakitsesaknafas.com/ http://obatsakitginjal.com/ http://obatsakitginjal.com/ http://obatalamisakitmaag.com/ http://obatalamisakitmaag.com/
- kfish 12y ago
  There’s a getting started guide to walkthrough a typical workflow: https://atlas.hashicorp.com/help/getting-started/getting-started-overview https://atlas.hashicorp.com/help/getting-started/getting-sta... In short: - `vagrant up` to bring up a development enviornment and make application changes - `vagrant push` to send application code - `packer push` to package software requirements to produce an artifact (AMI, Docker container, VMware image, many more) - `terraform apply` to deploy artifacts Important to note that each of these commands can be executed by different people in different sequences, and all changes are tracked in the Atlas Dashboard/UI.
  - mitchellh 12y ago
    I want to add to what Kevin said here (and disclaim that he is a HashiCorp employee) by saying that in a few months all of these steps will be possible via the web UI and without a command line interface or any knowledge of our open source at all. That is the direction we're heading. The current form of Atlas requires usage of our open source and is a tech preview showing what is coming and the direction we're heading. It is very much functional but we're going to make it a very slick system that does all of this for you without a CLI. For example, Atlas currently already runs Packer for you on our servers. We're going to extend that to everything.
  - Already__Taken 12y ago
    This is what I'm not getting; I have built a few projects with vagrant and it's annoying when working on the puppet files that I'm constantly installing php and httpd in the vagrant file just to try a new wordpress config. Should I be using packer to publish a mostly configured vagrant box. My vagrant steps just configure my app specifically for wordpress. Then use that box again in packer to publish it further?
alexatkeplar 12y ago
Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant (https://github.com/snowplow/dev-environment https://github.com/snowplow/dev-environment) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too. The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Golang, Terraform is bounded by the functionality of Hashicorp's own AWS client lib (https://github.com/mitchellh/goamz https://github.com/mitchellh/goamz), which hugely (and inevitably, given it's not a blessed 3rd-party library like boto) lags the official AWS clients (compare to e.g. https://github.com/aws/aws-sdk-java https://github.com/aws/aws-sdk-java). It's going to take something radical for Terraform to be relevant to sophisticated AWS users.
- eikenberry 12y ago
  Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API. With something that moves as fast as AWS this is great.
  - alexdean 12y ago
    I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormation using anything other than the Java client library is crazy IMO.
    - deleted 12y ago
      [deleted]
tobz 12y ago
What is a node in terms of pricing? Kinda/sorta feels like a stranglehold to have this remaining piece of the Hashicorp puzzle be free and then to start charging for it. :(
- mitchellh 12y ago
  Unlike our open source projects, Atlas is not shipping any foundational new functionality; it is unifying our open source projects into a single solution with a UI, security (ACLs, audits), workflow, etc. This differentiates it in being a commercial product and we feel this is a really clean way to do it. We've avoided any open core awkwardness and our business model is clear. To put it another way, we use an analogy internally here at HashiCorp: our open source are our "nuts and bolts" that you can grab off the shelf and be very successful with in building robust systems, but Atlas is the complete car or house (built up from these nuts and bolts) that you can purchase.
hardwaresofton 12y ago
As many have said, Hashicorp is awesome. What I particularly like about their products and their sites is that they take time to properly explain (and explain clearly) how their products fit into your stack, and what their intended use case is. Rather than random "we're working on something that will change devops forever" or similar marketing speak, the Atlas site lays out exactly what their vision for dev and ops is. The "how atlas works" section is brilliant. I know I'm just repeating what others have said, but as usual, great work. I think a lot of the work that Amazon has released this past few weeks is trying to get into precisely this space. To be the only company behind your code from development to deployment. I might be wrong, but I think hashicorp is in that space right with them.
ishbits 12y ago
I wonder if there will still be a free tier, a place to drop decent base nodes or images demoing open source and so on.
- mitchellh 12y ago
  There will, across all the features.
tapsboy 12y ago
Great job Hashicorp. Couldn't find my favorited public boxes, but could discover new boxes here https://vagrantcloud.com/boxes/search https://vagrantcloud.com/boxes/search
tsukassa 12y ago
Just in case someone is looking for something that already works and is open-source, we have been working on ĵeto for over a year ( http://jeto.io http://jeto.io ). You can host it on your own premises and there is support for many providers out of the box(vmware, lxc, amazon). The idea is pretty much the same, you have your vagrant project which calls different providers. You can checkout the dev version ( https://github.com/Pheromone/jeto-dev https://github.com/Pheromone/jeto-dev ) which prepackage everything. Proper documentation/tests and a real Getting Started guide is coming.
coreylane 12y ago
It's hidden right now but if you'd like to search for boxes use https://atlas.hashicorp.com/boxes/search https://atlas.hashicorp.com/boxes/search
niclupien 12y ago
Atlas as a project name seems very popular these days (Facebook Atlas API, o'Reilly Atlas platform, etc).

189 points by danielsiders 12y ago

There have been some cool tools coming out of Hashicorp, but I haven't read any experiences with people using their "full stack". Does anybody want to give their own anecdote or maybe have a link to related article?

throwaway8978 12y ago
They're not quite complete yet. I wish this was made more clear. Terraform has several bugs, some of them that will try and destroy perfectly good infrastructure for no reason (though it will warn you first). That said, their work is always good, it's just not complete yet, but it's branded as if it is.
tonglil 12y ago
- Vagrant is a given, wonderful. - Packer is for syncing VirtualBox, AWS AMIs, and what not for quick and stable starting points, also wonderful. - Consul is great for monitoring and running a services oriented architecture, haven't pushed it to its full potential though. - Serf: n/a, haven't tried yet. - Terraform: n/a. We are still using Ansible as the provisioner. Overall, good ecosystem, would recommend.
- jimmcslim 12y ago
  Consul is built on top of Serf (the protocol at least), so given you are already using Consul, Serf wouldn't add anything for you.
- Gigablah 12y ago
  We've been using Terraform extensively for our production deployment (a typical AWS setup with public/private subnets, load balancers, autoscaling groups, the works), and it works for the most part. There's still a hefty amount of bugs and many things will not function the way you expect, though usually you can work around them. Also the configuration language (HCL) is rough around the edges and the variable interpolation gotchas can be very frustrating.
- porker 12y ago
  > - Vagrant is a given, wonderful. It's really useful, but on my MBP I've found using it abysmally slow (VirtualBox backend, website code shared using NFS, DB and everything else stored in VirtualBox VM and not shared folders) - page load times taking upwards of 20s (sometimes even a minute) when running direct on my MBP would be under 0.3s. Never figured out the issue, in spite of extensive research and tweaking. Replace VirtualBox with VMWare Fusion? But without a trial available of the Vagrant addon, bit of an expensive gamble.
  - jesseendahl 12y ago
    Apparently syncing file changes between the VM and host via rsync leads to a lot better performance than using NFS. Worth a shot at least: https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-rsync.html https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-r... http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-shared-folder http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-a...
  - kcorbitt 12y ago
    I have the same Vagrant setup you do (nfs-shared app directory, everything else inside the vagrant box), and while I see overheads of 1.5-2x, I've never seen anything like the 60x overheads you're describing here. Something seems off in your configuration. Perhaps you're memory-limited and the vagrant box is thrashing your swap file every time you make a request?
  - steveax 12y ago
    My personal experience is that the VMware provider is much snappier - and more stable too. The provider is what, $80 US? Not sure I'd call that an expensive gamble b
  - tszming 12y ago
    try SMB instead of NFS
witten 12y ago
Haven't used their full stack, but their "support" leaves a lot to be desired.
- mitchellh 12y ago
  Our support has been strained and historically been slow, but for the past couple months, our average support time has dropped down to less than a day! We recognized the issue there and hopefully you'll have a much better experience from here on out. "Bad support" is not the company we want to be. Sorry for the poor experience you had.
  - throwaway8978 12y ago
    I got no response when asking about when a bug that was fixed in an upstream library might lead to a new binary being released. It'd at least be nice to hear "I have no idea, we're busy."

dang 12y ago

A related TechCrunch story: https://news.ycombinator.com/item?id=8727842 https://news.ycombinator.com/item?id=8727842. We're probably going to build a way to group related stories more explicitly, but manually posted comments will have to do for now.

simonebrunozzi 12y ago
+1!
kolev 12y ago
Maybe we should establish a linking convention so that these can be converted later more easily. For example, <url> #related.
- deleted 12y ago
  [deleted]
applecore 12y ago
That's an interesting idea, but I hope it's pretty low on the to-do list, since posting a comment with additional links already works well. (A comment can be posted by anyone, voted up or down, or submitted as a separate item.)

joesmo 12y ago

Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs to save time. I would never use it or any tech built on top of it in development, let alone production.

malandrew 12y ago
They really need to rewrite it in go. Ruby has been a disaster for this particular project. Don't even get me started on the Nokogiri issues. Everything they've written in go has functioned better IMHO.
- FooBarWidget 12y ago
  Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
  - sciurus 12y ago
    Even if you use their all-in-one package, you can still have dependency problems installing vagrant plugins. https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/4278 https://github.com/mitchellh/vagrant/issues/4278
    - FooBarWidget 12y ago
      Yeah but those are plugins, the Vagrant author can't do anything about what third parties do. You mentioned Go as a better language, but Go does not solve that problem it does not support loadable modules at all. If Vagrant were written in Go it wouldn't have supported plugins at all.
  - dandandan 12y ago
    It was much more stable for me when I was installing it through rubygems and managing our middleware's dependencies with bundler directly. We've switched to the embedded ruby and it's a struggle but we deal with it since it's probably MUCH less work to support now that it's standardized across all vagrant installs.

wallflower 12y ago

Great job, Hashicorp! Exciting to see the shift from clunky, heavy-weight versioned Chef cookbooks/Puppet modules that attempt to prevent 'server drift' by walking the directed graph for all dependencies with server convergence to true service registries like Consul and build images. Amazon CloudFormation is pretty clunky when it comes to updating user data in the CF stack template that is passed to the resources. Sometimes it even thinks you didn't update anything. Having the file-based template update itself via consul-template seems like a more sane approach. I am curious how the 'Maintain' part of the autoscaling works given that Amazon AWS has pretty crude autoscaling mechanisms available if you use only what CloudWatch offers. Hoping that 'Maintain' can be given a set of inputs on server health/application responsiveness and decide whether to scale up or scale down. Also, integration with some kind of historical/real-time cost engine would be a great feature to figure out future/past billing for cloud services.

eaurouge 12y ago

Any plans to support other providers, like DigitalOcean for instance?

mitchellh 12y ago
Many, many more providers are along the way. The providers already exist in the open source so its just a matter of enabling them one at a time in Atlas. But we have some surprises planned for some of them as well. :)

deleted 12y ago

[deleted]

keithchambers 12y ago

We use Vagrant, Packer, and Consul with multiple SaaS products here at Cisco. We love the Hashicorp product family and team!

akurilin 12y ago

Looks very interesting! Would be great to get an idea of what a typical workflow with this paradigm would look like.

ujangsopian 12y ago
a lot of useful information on this website thanks a lot yes http://obatpenyakitsesaknafas.com/ http://obatpenyakitsesaknafas.com/ http://obatsakitginjal.com/ http://obatsakitginjal.com/ http://obatalamisakitmaag.com/ http://obatalamisakitmaag.com/
kfish 12y ago
There’s a getting started guide to walkthrough a typical workflow: https://atlas.hashicorp.com/help/getting-started/getting-started-overview https://atlas.hashicorp.com/help/getting-started/getting-sta... In short: - `vagrant up` to bring up a development enviornment and make application changes - `vagrant push` to send application code - `packer push` to package software requirements to produce an artifact (AMI, Docker container, VMware image, many more) - `terraform apply` to deploy artifacts Important to note that each of these commands can be executed by different people in different sequences, and all changes are tracked in the Atlas Dashboard/UI.
- mitchellh 12y ago
  I want to add to what Kevin said here (and disclaim that he is a HashiCorp employee) by saying that in a few months all of these steps will be possible via the web UI and without a command line interface or any knowledge of our open source at all. That is the direction we're heading. The current form of Atlas requires usage of our open source and is a tech preview showing what is coming and the direction we're heading. It is very much functional but we're going to make it a very slick system that does all of this for you without a CLI. For example, Atlas currently already runs Packer for you on our servers. We're going to extend that to everything.
- Already__Taken 12y ago
  This is what I'm not getting; I have built a few projects with vagrant and it's annoying when working on the puppet files that I'm constantly installing php and httpd in the vagrant file just to try a new wordpress config. Should I be using packer to publish a mostly configured vagrant box. My vagrant steps just configure my app specifically for wordpress. Then use that box again in packer to publish it further?

alexatkeplar 12y ago

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant (https://github.com/snowplow/dev-environment https://github.com/snowplow/dev-environment) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too. The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Golang, Terraform is bounded by the functionality of Hashicorp's own AWS client lib (https://github.com/mitchellh/goamz https://github.com/mitchellh/goamz), which hugely (and inevitably, given it's not a blessed 3rd-party library like boto) lags the official AWS clients (compare to e.g. https://github.com/aws/aws-sdk-java https://github.com/aws/aws-sdk-java). It's going to take something radical for Terraform to be relevant to sophisticated AWS users.

eikenberry 12y ago
Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API. With something that moves as fast as AWS this is great.
- alexdean 12y ago
  I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormation using anything other than the Java client library is crazy IMO.
  - deleted 12y ago
    [deleted]

tobz 12y ago

What is a node in terms of pricing? Kinda/sorta feels like a stranglehold to have this remaining piece of the Hashicorp puzzle be free and then to start charging for it. :(

mitchellh 12y ago
Unlike our open source projects, Atlas is not shipping any foundational new functionality; it is unifying our open source projects into a single solution with a UI, security (ACLs, audits), workflow, etc. This differentiates it in being a commercial product and we feel this is a really clean way to do it. We've avoided any open core awkwardness and our business model is clear. To put it another way, we use an analogy internally here at HashiCorp: our open source are our "nuts and bolts" that you can grab off the shelf and be very successful with in building robust systems, but Atlas is the complete car or house (built up from these nuts and bolts) that you can purchase.

hardwaresofton 12y ago

As many have said, Hashicorp is awesome. What I particularly like about their products and their sites is that they take time to properly explain (and explain clearly) how their products fit into your stack, and what their intended use case is. Rather than random "we're working on something that will change devops forever" or similar marketing speak, the Atlas site lays out exactly what their vision for dev and ops is. The "how atlas works" section is brilliant. I know I'm just repeating what others have said, but as usual, great work. I think a lot of the work that Amazon has released this past few weeks is trying to get into precisely this space. To be the only company behind your code from development to deployment. I might be wrong, but I think hashicorp is in that space right with them.

ishbits 12y ago

I wonder if there will still be a free tier, a place to drop decent base nodes or images demoing open source and so on.

mitchellh 12y ago
There will, across all the features.

tapsboy 12y ago

Great job Hashicorp. Couldn't find my favorited public boxes, but could discover new boxes here https://vagrantcloud.com/boxes/search https://vagrantcloud.com/boxes/search

tsukassa 12y ago

Just in case someone is looking for something that already works and is open-source, we have been working on ĵeto for over a year ( http://jeto.io http://jeto.io ). You can host it on your own premises and there is support for many providers out of the box(vmware, lxc, amazon). The idea is pretty much the same, you have your vagrant project which calls different providers. You can checkout the dev version ( https://github.com/Pheromone/jeto-dev https://github.com/Pheromone/jeto-dev ) which prepackage everything. Proper documentation/tests and a real Getting Started guide is coming.

coreylane 12y ago

It's hidden right now but if you'd like to search for boxes use https://atlas.hashicorp.com/boxes/search https://atlas.hashicorp.com/boxes/search

niclupien 12y ago

Atlas as a project name seems very popular these days (Facebook Atlas API, o'Reilly Atlas platform, etc).