21–30 of 57 posts
Looks very interesting! Would be great to get an idea of what a typical workflow with this paradigm would look like.
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.
Looks very interesting! Would be great to get an idea of what a typical workflow with this paradigm would look like.
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.
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.
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.
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.
Maybe we should establish a linking convention so that these can be converted later more easily. For example, #related.
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…
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.
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.
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?
- 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.
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?
- 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.
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.