Live data from Hacker News

Atlas by Hashicorp

atlas.hashicorp.com

41–50 of 57 posts

Re: Atlas by Hashicorp

#41
post #23

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 arti…

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?

Re: Atlas by Hashicorp

#42
post #4

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.

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

Re: Atlas by Hashicorp

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

Re: Atlas by Hashicorp

#44
post #30
post #5

Earlier quoted context omitted.

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

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

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

Re: Atlas by Hashicorp

#46

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 Gola…

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

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

Re: Atlas by Hashicorp

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

Re: Atlas by Hashicorp

#49
post #30
post #5

Earlier quoted context omitted.

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

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

try SMB instead of NFS

Re: Atlas by Hashicorp

#50

Earlier quoted context omitted.

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

Post reply on HN