4 ms·

This really resonates with me. I have been having identical issues with Dotcloud, a Heroku competitor. There's nothing worse than wondering if deploying your s

by memset 13y ago

This really resonates with me. I have been having identical issues with Dotcloud, a Heroku competitor. There's nothing worse than wondering if deploying your stupid one-character typo fix will hang or leave the app in an incomplete state. I myself am working on setting up salt stack for deployments. I like that all of it is in python, and after a couple of days I've begun to make progress. I am migrating things slowly: first cron jobs, then internal tools, and at some point, our website. The only thing that really needs "scale" is our frontend, and I don't yet know how I'll manage that, but you know, I guess it is time to learn!

deleted 13y ago
[deleted]
scottvdp 13y ago
Huge fan of salt stack, and I may push Adrian in that direction. The changes we made here were minimal in the way he deploys, and with so many architecture changes behind the scenes, we decided less is more on that front.
- bsaul 13y ago
  any link on the advantage of using saltstack for aws instead of AMIs ?
  - scott_w 13y ago
    Salt is more easily repeatable across heterogeneous environments. For example, we're using Salt to manage our development, testing, staging and production environments. We couldn't do this with AMIs, since the environments are quite different. It makes updating quite easy, as you don't need to create a new AMI, just push your update to your release branch, then run state.highstate from your Master. If you configuration changes, you update the master and then you can push that change across all (or just one) of your environments.
tlrobinson 13y ago
Does having an identical staging environment help, or are these deploy errors transient/non-deterministic?
- memset 13y ago
  The latter, unfortunately. (I wish I had more details - but for one reason or another, it never seems to work, be it a bug in the deployment system or a host which is down.) Dreams of an identical staging environment were somewhat shattered when the "free tier" plans went away. Plus, sometimes a new version will be deployed to 2 servers, and the 3rd one will be hanging on an update. These kinds of things are difficult to plan for and test, since intentionally messing up a deployment is rather difficult with PaaS.
tlrobinson 13y ago
Does having an identical staging environment help, or are these deploy errors transient/non-deterministic?
Spiritus 13y ago
Shame, I was looking into Dotcloud just the other day and liked the more control they gave you, especially the custom nginx conf. And that they hosted static files for you instead of relying on third party services (i.e. S3).
bsaul 13y ago
i'm starting a process to deploy on aws, and i just finished creating my salt stack conf for a vagrant VM ( as a warm up). After reading the post i was in the process of ditching that for a simpler AMI-based deployment. Could you elaborate on why salt stack is better than custom AMIs ? also if you have any link explaining how to deploy to ec2 using saltstack, that would be awesome.
- 23david 13y ago
  AMIs are really useful for production servers when you want to quickly launch a bunch of similar servers or set up auto-scaling groups to launch new servers based on load. The issue is that to take full advantage of using AMIs, you need to re-build (bake) the AMI every time you make a change to your production machines. Disadvantages of AMIs are that they are large files (which can be unwieldy) and are not in a format that can be immediately used in a vagrant instance or elsewhere, so you need to convert between AMI and .vbox or .box formats to use amis with your local vagrant instance. With saltstack, you can deploy and configure machines from base Ubuntu or RHEL distros by using salty-vagrant for vagrant instances and salt-cloud for AWS / rackspace / openstack / vps machines. Once machines are deployed and connected to your salt-master, you can use your yaml config files to bring all the machines to the desired roles (api machine, load balancer, web front-end, etc.). This is more flexible than using AMIs, since you can roll out a minor change quickly to all servers, including production servers, without needing to wait to build a new AMI. There are hybrid approaches also (some puppet/chef users do this) where for production machines you can have saltstack deploy to a machine that then gets built into a new AMI automatically. And then this new AMI gets updated into the autoscaling groups and is deployed to replace the current production servers. Sounds complicated... and it is, but at the cost of extra complexity it does give you the best of both worlds.
  - bsaul 13y ago
    Thanks, Sounds like the last option seems the best indeed. My salt configuration is way too slow to build to be used in an autoscaling scenario, that's one reason why AMI seemed suitable to me, but that last combination you mentioned (which i didn't know was possible) looks great. Thanks again

by memset 13y ago

deleted 13y ago

[deleted]

scottvdp 13y ago

Huge fan of salt stack, and I may push Adrian in that direction. The changes we made here were minimal in the way he deploys, and with so many architecture changes behind the scenes, we decided less is more on that front.

bsaul 13y ago
any link on the advantage of using saltstack for aws instead of AMIs ?
- scott_w 13y ago
  Salt is more easily repeatable across heterogeneous environments. For example, we're using Salt to manage our development, testing, staging and production environments. We couldn't do this with AMIs, since the environments are quite different. It makes updating quite easy, as you don't need to create a new AMI, just push your update to your release branch, then run state.highstate from your Master. If you configuration changes, you update the master and then you can push that change across all (or just one) of your environments.

tlrobinson 13y ago

Does having an identical staging environment help, or are these deploy errors transient/non-deterministic?

memset 13y ago
The latter, unfortunately. (I wish I had more details - but for one reason or another, it never seems to work, be it a bug in the deployment system or a host which is down.) Dreams of an identical staging environment were somewhat shattered when the "free tier" plans went away. Plus, sometimes a new version will be deployed to 2 servers, and the 3rd one will be hanging on an update. These kinds of things are difficult to plan for and test, since intentionally messing up a deployment is rather difficult with PaaS.

tlrobinson 13y ago

Does having an identical staging environment help, or are these deploy errors transient/non-deterministic?

Spiritus 13y ago

Shame, I was looking into Dotcloud just the other day and liked the more control they gave you, especially the custom nginx conf. And that they hosted static files for you instead of relying on third party services (i.e. S3).

bsaul 13y ago

i'm starting a process to deploy on aws, and i just finished creating my salt stack conf for a vagrant VM ( as a warm up). After reading the post i was in the process of ditching that for a simpler AMI-based deployment. Could you elaborate on why salt stack is better than custom AMIs ? also if you have any link explaining how to deploy to ec2 using saltstack, that would be awesome.

23david 13y ago
AMIs are really useful for production servers when you want to quickly launch a bunch of similar servers or set up auto-scaling groups to launch new servers based on load. The issue is that to take full advantage of using AMIs, you need to re-build (bake) the AMI every time you make a change to your production machines. Disadvantages of AMIs are that they are large files (which can be unwieldy) and are not in a format that can be immediately used in a vagrant instance or elsewhere, so you need to convert between AMI and .vbox or .box formats to use amis with your local vagrant instance. With saltstack, you can deploy and configure machines from base Ubuntu or RHEL distros by using salty-vagrant for vagrant instances and salt-cloud for AWS / rackspace / openstack / vps machines. Once machines are deployed and connected to your salt-master, you can use your yaml config files to bring all the machines to the desired roles (api machine, load balancer, web front-end, etc.). This is more flexible than using AMIs, since you can roll out a minor change quickly to all servers, including production servers, without needing to wait to build a new AMI. There are hybrid approaches also (some puppet/chef users do this) where for production machines you can have saltstack deploy to a machine that then gets built into a new AMI automatically. And then this new AMI gets updated into the autoscaling groups and is deployed to replace the current production servers. Sounds complicated... and it is, but at the cost of extra complexity it does give you the best of both worlds.
- bsaul 13y ago
  Thanks, Sounds like the last option seems the best indeed. My salt configuration is way too slow to build to be used in an autoscaling scenario, that's one reason why AMI seemed suitable to me, but that last combination you mentioned (which i didn't know was possible) looks great. Thanks again