Atlas by Hashicorp | Hacker News Reader

Atlas by Hashicorp

atlas.hashicorp.com

189 pointsdanielsiders52 comments

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant (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), 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). It's going to take something radical for Terraform to be relevant to sophisticated AWS users.

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.

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

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.

The .NET sdk is pretty fantastic as well.

But anyway, goamz is "Hashicorp's" AWS Go SDK in that Hashicorp forked it and refused to work with the larger community because it's "critical" to their business. This has, at least until super recently, stranded certain functionality into the different forks and severely fractured the AWS Go offerings. True story.

Ultimately, what the Go community probably needs most is Amazon to step up and support a Go SDK officially. The Java, Ruby, .Net, and even Python SDK's are very robust at this point. I can't speak to the others.

Good to hear about the .NET library. I hadn't heard the story about goamz, that's unfortunate. I do know that there are SDKs which Amazon _only_ make available in Java and Python, e.g. the Kinesis Client Library (http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record...).

This Clojure library agrees with you, it reflects and post-processes the AWS Java library. https://github.com/mcohen01/amazonica

The sequence at AWS seems to be:

  1. Announce something in a blog post (sometimes get everyone really excited)
  2. Add access to that feature/setting in the AWS Web UI
  3. Add access to that in the official API
  4. Add access to that in aws-cli
  5. Add access to that in cloud formation stack creation

It seems sometimes weeks and months lag between steps (e.g. steps 2 to 3).

(Apologies for the self-promotion, but it's at least on-topic.)

I just opened up this repo yesterday: https://github.com/stripe/aws-go.

It's really raw, but it uses the JSON API descriptions from botocore to generate Go clients for all 40 public AWS services.

A related TechCrunch story: 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.

+1!

Maybe we should establish a linking convention so that these can be converted later more easily. For example, <url> #related.

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.)

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?

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.

- 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.

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.

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.

> - 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.

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-r... http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-a...

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?

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

try SMB instead of NFS

Haven't used their full stack, but their "support" leaves a lot to be desired.

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.

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."

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

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.

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.

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. :(

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.

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

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

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

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. :)

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.

There will, across all the features.

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

There’s a getting started guide to walkthrough a typical workflow: 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.

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.

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?

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

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 ). 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 ) which prepackage everything.

Proper documentation/tests and a real Getting Started guide is coming.

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.

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.

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.

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/4278

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.

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.

Interesting. I haven't experienced any such issues personally.

I have been using Vagrant daily, for little over a year and a half, to create fairly complex muli-node lab environments, and have not had similar experiences. The thought of going back to manually doing this again is not a pleasant one! I guess there are a couple places you could look: the OS images you are using (if they are flakey then the entire chain breaks), your machine (SSD makes things go quickly), your vagrant install (try upgrading), your virtualization software (try upgrading), etc. If there are real bugs, then file them on the Vagrant github page [1], and hopefully we can all benefit from the fixes.

[1] https://github.com/mitchellh/vagrant/issues

For all of the issues I have been facing, most of them were actually triggered by virtualbox. Those issues can be quite annoying but can be solved quite easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I had major issues with those) does the job. On the other side, Vagrant has got some minor issues but let's face it: doing what Vagrant does manually is huge and I prefer composing with those issues than being on my own. When VB works well and don't cause any problem, you can do quite complex setups with Vagrant. I already created a swarm of 5 VMs on my machine to test my deployments locally: Vagrant may not be imperatively useful for developers but I think it's essential for everyone working on deployment and having the devs using it too can greatly improve the life of those deploying the apps. One last point: Vagrant is not made for production and I think Hashicorp has been pretty clear on that. I never tested packer/terraform or consul so I won't say anything on the production-side of what they're doing but I won't judge it until I actually used it. Vagrant may have evolved since the last time you used it, you should give it another chance !

I would consider using it again if I really had to for more than just quickly testing a VM, but to be honest, after wasting days with problems (which the vagrant team is aware of) and then having it fail again and again, I'm not very inclined to. I can see why vagrant encourages a workflow where one destroys the VMs regularly as that would likely avoid a ton of issues at the expense of time wasted.

My VMWare machines have been problem free for many months (as well as my manual VBox ones for years) and the only way I'd even consider using it daily again by choice again is to try out their VMWare support ... which is unfortunately paid so I doubt that will happen. On the other hand, using vagrant did point out some severe weaknesses in VirtualBox itself, especially the file syncing support, and made me realize VMWare is worth the money for that alone. I still use vagrant once in awhile if I only need to test a project out for an hour or two.

As far as deployment, I could see the potential time savings when dealing with multiple VMs but those would only be realized if they're not offset by a longer time spent dealing with bugs. Still, I may give it another shot in that context when the need arises next.

Reply on news.ycombinator.com