Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS CodeDeploy

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: AWS CodeDeploy

#21

Post by sciurus »

STRML wrote: post #20

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, an…

CloudFormation is really a different beast. It's focused on creating and managing related collections of AWS resources, not on application deployment. Anyone doing, well, pretty much anything on AWS should probably be using Cloudformation.

http://aws.amazon.com/cloudformation/

Re: AWS CodeDeploy

#22

Post by kxo »

STRML wrote: post #20

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, an…

How about an Amazon-managed Docker (not shit ElasticBeanstalk) infrastructure/config management system?

If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.

Re: AWS CodeDeploy

#23

Post by STRML »

kxo wrote: post #22
STRML wrote: post #20

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, an…

How about an Amazon-managed Docker (not shit ElasticBeanstalk) infrastructure/config management system? If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.

From my understanding, after talking to them at Web Summit, something like this is in the works. And they're aware of how incredibly complicated the AWS console is becoming. I don't know how or when they plan to address it, however.

Re: AWS CodeDeploy

#24

Post by mwarkentin »

fmotlik wrote: post #17
ryanfitz wrote: post #6

I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…

I've been working on the CodeDeploy Integration here at Codeship and have been working with the service for a bit (as a preface on my thoughts) While Immutable Infrastructure is also in our opinion (and I've written about this extensively) the way to go in the future updating systems in place is still the primary way to deploy systems and will be for a while. By providing a centralized systems to upload new released…

Have you written anywhere how you guys deal with operational monitoring (eg. Boundary, New Relic, etc.) when you're spinning up brand new instances all of the time?

Re: AWS CodeDeploy

#26

Post by rev_bird »

samstokes wrote: post #4

This could be a big deal in terms of raising the bar for deployment practices. Right now "nobody ever got fired for" setting up deployment via rsync and some ad-hoc shell scripts. That works for a single host, although it's not great for reproducibility. But as soon as you go to multiple hosts you need some degree of orchestration, monitoring, and integration with your load balancer to avoid downtime. CodeDeploy offe…

If the job is "get an app onto a bunch of boxes and load balance the healthy ones," I feel like AWS has already been doing that for a long time – deploy your code to a box, create an AMI from the box, and use it as a launch configuration for an auto scaling group. New code=new box=new AMI, and then you don't have to worry about the mechanics of moving code to a bunch of boxes at the same time.

This seems like a tiny step forward for orgs who are deploying code to boxes that they never take down, but for the orgs that have been doing it the AWS-prescribed (immutable) way, I'm having trouble seeing how this is useful at all.

Re: AWS CodeDeploy

#27

Post by tedchs »

kxo wrote: post #22
STRML wrote: post #20

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, an…

How about an Amazon-managed Docker (not shit ElasticBeanstalk) infrastructure/config management system? If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.

On Google Cloud Platform, there is a new service called Google Container Engine (currently in alpha). It uses Kubernetes to manage Docker containers, running on Google Compute Engine. You could also run Kubernetes on EC2 if you wanted to.

Re: AWS CodeDeploy

#28

Post by zackangelo »

STRML wrote: post #20

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, an…

I've found developing OpsWorks recipes directly on the instance to be the best remedy for the slow feedback cycle.

Your cookbook is located /opt/aws/opsworks/current/site-cookbooks. If you run a command from the web console, you can repeat the command with a tailed log output using "opsworks-agent-cli run_command".

Re: AWS CodeDeploy

#29

Post by fmotlik »

mwarkentin wrote: post #24
fmotlik wrote: post #17

Earlier quoted context omitted.

I've been working on the CodeDeploy Integration here at Codeship and have been working with the service for a bit (as a preface on my thoughts) While Immutable Infrastructure is also in our opinion (and I've written about this extensively) the way to go in the future updating systems in place is still the primary way to deploy systems and will be for a while. By providing a centralized systems to upload new released…

Have you written anywhere how you guys deal with operational monitoring (eg. Boundary, New Relic, etc.) when you're spinning up brand new instances all of the time?

A bit: http://blog.codeship.com/lxc-memory-limit/

We use librato for monitoring our build server infrastructure and mostly only look at max/min values for metrics that could mean trouble. Generally we're able to separate data of different instances by their instance id so we could look into them individually.

We use NewRelic for our Rails application on Heroku and pump Heroku data into Librato as well (we love data and metrics)

And of course you can always send me an email to flo@codeship.com with questions.

Re: AWS CodeDeploy

#30

Post by ermintrude »

bashtoni wrote: post #13
ryanfitz wrote: post #6

I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…

Yep, this is Amazon reaching out to those who won't/can't take the 'immutable infrastructure' approach. It's fair to say if you're already doing things in the way you describe, this service isn't for you.

Baking everything into AMIs is the "right" way to go, but if AWS had a supported, hosted git server inside their network to push into, I'd rather have the speed of deploying from git, and only bake AMIs when necessary for system upgrades.
Post reply on HN