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

Docker Releases Plugin for Simplified Deployments into AWS

infoq.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: Docker Releases Plugin for Simplified Deployments into AWS

#61

Post by mcintyre1994 »

irjustin wrote: post #51
mcintyre1994 wrote: post #20

Earlier quoted context omitted.

Yep I definitely agree with the importance, it’s probably the most impactful technical debt we have. Clone environments is a big driving force for it too. I guess what I was hoping is that Beanstalk wasn’t designed with infra as code in mind, but things like Fargate were, and somehow it had become less horrible. Maybe that’s just never going to happen though and it’s the nature of the problem. Appreciate the pointer…

The code differences between ElasticBeanstalk and Fargate are not very far, but JUST far enough to be annoying. Because you've worked with Beanstalk in the past, I would personally stick with it unless I'm looking to fight 2 issues at the same time - Learning Fargate & Learning CDK/CloudF/Terraform. Fargate is not a panacea - Elastic Beanstalk does have very cool options/features.

I really appreciate the insight here - thanks a lot :)

Re: Docker Releases Plugin for Simplified Deployments into AWS

#62

Post by heliodor »

sacredcows wrote: post #59
heliodor wrote: post #53

Earlier quoted context omitted.

Unrelated, why are you using parallax effects on your landing page? It works really poorly when I scroll down fast.

Scroll down slower

I tried but when I scroll down slower I have to wait for the content to slide in from the left or from the right, or to assemble at random. Still no good.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#63

Post by kristianpaul »

irjustin wrote: post #7

I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…

Give a Try to CDK constructs for fargate (ecs-patterns) and Assets for registering Dockerfiles as ECR repos

Re: Docker Releases Plugin for Simplified Deployments into AWS

#64

Post by rubber_duck »

secondcoming wrote: post #57
b112 wrote: post #47

Earlier quoted context omitted.

The real problem is, people are deploying dozens of different coding languages, any technology that whimsically passes by, and replacing simple, streamlined monolith technology with 100 micro services. All of this is endlessly pushed by AWS, Google, Docker, and anyone else with a foot in the "Snag as much cash from DEVs" crowd. Other old timers will explain how they ran thousands of hits/second on 6 or 7 bare metal s…

It's a totally valid rant, and one that I enthusiastically agree with. I work in adtech (apologies). We have maybe 10 - 15 instances (16 vCPUs, 31GB RAM) that each handle 10k+ HTTP requests per second. There's a push to dockerise all this. I don't see the point. I've often wondered about the potential performance loss of Dockerising all this, do you have public numbers available? We recently hired a ex-Googler to a m…

Well it should be faster if you're replacing the VM layer and running docker on top of bare metal kernels, in theory you could use a cheap dedicated hosting provider to host a K8S cluster and probably outperform a managed cloud offering price and performance wise - but in practice this shit is so unreliable I would never want to be the guy on call maintaining this - they would need to pay me a lot more than the delta between managed cluster and bare metal. For non-critical computationally expensive stuff like analytics and BI it could make sense.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#65

Post by hnlmorg »

scaryclam wrote: post #48
ramraj07 wrote: post #13

Earlier quoted context omitted.

Could you comment on why you are moving away from elastic beanstalk? We manage a fairly simple EB deployment but it seems perfect for our infra needs, and I'm not able to imagine why we might need to scale out of it - if any other services are required, I'm tempted to only launch multiple EB deployments instead of going the kubernetes/fargate route.

EB is very limiting. If you want to deviate from it's prescribed path at all, things become a giant headache. Then there's issues with when it goes wrong. Troubleshooting is really hard, and knowing what actually went wrong requires a ton of digging around, and god forbid the environment gets stuck in a warning state. You can only download logs when it's "OK", so you're pretty much SOL if this happens. There's also t…

This, absolutely this. If you don't have anyone on your team with sysadmin / DevOps experience then EB is an option. However when it breaks, and it does, it's a nightmare to get working again.

Terraform is a nightmare to learn for the first time but once you've wrapped your head around it, it's a thousand times better than EB. If Terraform is too complex for your needs then use CloudFormation directly instead of EB.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#66

Post by tholford »

oblio wrote: post #31
solarist wrote: post #30

Earlier quoted context omitted.

Have you heard of Mark Twain by any chance? People say he used to write in English.

Cool! I didn't know it was an expression coined (or made popular?) by him. And I actually read many of Mark Twain's works in Romanian, so, oh well... ¯\_(ツ)_/¯

"If you need to eat a frog, do it in the morning; if you need to eat two, start with the bigger one" (paraphrased)

Re: Docker Releases Plugin for Simplified Deployments into AWS

#67

Post by indemnity »

irjustin wrote: post #7

I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…

I just spent this weekend setting this up to learn a bit of AWS for a toy project. I thought I would "just" quickly drop a Rust API server image in an ECS cluster.

By the end of the weekend, I had the architecture you describe.

- Route53 alias A record -> ALB DNS name

- LetsEncrypt cert in IAM

- ALB listener doing SSL termination using the cert -> forwarding to target group

- ALB listener doing 80->443 redirect

- Security group on ALB listener allowing only approved IP ranges in (not ready for this thing to be public yet)

- Security group on ECS service only allowing ALB to connect

- ECS cluster using Fargate

- RDS instance only allowing ECS service to connect

- CloudWatch log group for the container logs

- Subnets

- Secrets Manager for pulling Docker images from private GitHub Packages repo

Did it all in Terraform, and then added GitHub Actions to the Terraform repository to do terraform validate on PR and terraform plan && terraform apply -auto-approve on merge.

Then, yesterday, hooked up GitHub Actions on the Rust API server repository build a version tagged image and publish it to GitHub packages, create a PR in the Terraform repository to update the ECS task definition for the new image, and if it passes the PR checks, automatically merge it (which triggers the Terraform plan/apply run).

It did seem complex the first time I did it, but looking back over both the AWS and GitHub Actions configuration, I wouldn't change too much. I feel fairly confident this is secure, and I understand most of the configuration options and why they are there. Something that "simplified" it for me would just become a straightjacket as I get more proficient with AWS.

IaC 101 I guess, but I was chuffed when the Rube Goldberg machine whirred away after making a code commit to the Rust repo, and two minutes later my new code was running on ECS :)

Considering writing up a blog post about it just to firm up my own understanding as well...

Re: Docker Releases Plugin for Simplified Deployments into AWS

#68

Post by jcims »

sp332 wrote: post #58
clappski wrote: post #43

Earlier quoted context omitted.

You can create/resize/delete non-root EBS volumes without any downtime of the attached host(s), as far as I'm aware? Pretty sure I've done so in the past. You'll have to resize2fs or whatever but it shouldn't take any downtime.

EBS is not "compute-attached". GP means the disks that appear to be local to the instance.

EBS volumes appear local to the machine.

    [ec2-user@ip-1-1-1-1 ~]$ sudo fdisk -l
    Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Disk identifier: 0D7E094F-1C63-43F2-AC82-3316E992075B
    
    Device       Start      End  Sectors Size Type
    /dev/xvda1    4096 16777182 16773087   8G Linux filesystem
    /dev/xvda128  2048     4095     2048   1M BIOS boot
    
    Partition table entries are not in disk order.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#69

Post by jeremylevy »

At my current startup, we're building something like this.

A "catalog" of architectures that you could use to create a complete cloud architecture on your AWS, GCP or Azure account in less than one minute.

For example, you could create a docker-based architecture with CI/CD, auto-scaling, zero downtime deployment, SSL, load-balancing, high availability and MongoDB in less than one minute in your own AWS account.

Like Terraform with the user-friendliness of Heroku.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#70

Post by FunnyLookinHat »

techntoke wrote: post #42
SingAlong wrote: post #39

Earlier quoted context omitted.

I'm working on a command-line deployment tool that deploys to DigitalOcean and AWS LightSail (to start with). This is based on my experience deploying apps. I expect to finish the remaining work in the next few weeks. Can I contact you to try it out? (My email is on my profile)

You mean like Terraform?

Terraform is so heavy handed - I wouldn't call it a deployment tool. It's more of a means to build out infrastructure in AWS.

Once you get your AWS account setup there's still virtually no tooling to actually manage deploys of new code into that infrastructure. We're going to hand roll some tooling on top of aws-cli most likely.

Post reply on HN