Live data from Hacker News

Docker Releases Plugin for Simplified Deployments into AWS

infoq.com

81–90 of 116 posts

Re: Docker Releases Plugin for Simplified Deployments into AWS

#81

Earlier quoted context omitted.

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.

It took me half an hour and a 30-line (with spaces) terraform file to get a Lightsail instance up with static ip, running wordpress.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#82
post #47

None of this is simple. We're drowning in YAML files. It's difficult to maintain. Jinja + ansible + helm... it's a joke. There must be a better way of doing all this.

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…

Docker images are just lighter weight VMs. Or to be more accurate, they accomplish the same goals as full VMs in a different way.

If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server.

You're also conflating different problems here. If someone is writing poor SQL it doesn't matter if their deploying with a VM, Docker, or onto a bare metal server.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#83
post #44

Earlier quoted context omitted.

Largely I don't think it's worth moving off EB except in specific scenarios. I'm a Rails monolith and DB migrations are not well suited in ElasticBeanstalk when running docker containers. There's no way to run a single container that 'completes' and then returns whether it was successful or not. Currently I have a separate environment that holds a single EC2 (lots of idle time) to run migrations. It fires and the dep…

We have a similar setup — containers managed by Fargate — and solved the issue of migrations by: 1) having our app containers include the DB migration logic 2) on container startup, “check and run migrations” before app startup, 3) the trick: acquire a lock in postgres as part of step 2, so that only one node at a time can run migrations. Migrations are run inside of a begin/commit, so with the lock we have reliable…

As I understand it, the concurrency-safe lock is built into Rails for a while. Step 3 shouldn’t be necessary.

https://github.com/rails/rails/pull/22122

Re: Docker Releases Plugin for Simplified Deployments into AWS

#84
post #82
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…

Docker images are just lighter weight VMs. Or to be more accurate, they accomplish the same goals as full VMs in a different way. If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server. You're also conflating different problems here. If someone is writing poor SQL it doesn't matter if their deploying with a VM, Docker, or onto a bare metal se…

> If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server.

Until a bug in Docker, or the CNI abstraction, or some resource hangs/panics the kernel on the bare metal, and then you have to reboot the whole thing taking out all the containers.

This gets rarer, and rarer, as the bugs get ironed out, of course, but In my 20+ year anecdotal experience, a kernel running just a bunch of VM's crashes far less frequently than a kernel running containers.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#85
post #82
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…

Docker images are just lighter weight VMs. Or to be more accurate, they accomplish the same goals as full VMs in a different way. If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server. You're also conflating different problems here. If someone is writing poor SQL it doesn't matter if their deploying with a VM, Docker, or onto a bare metal se…

> they accomplish the same goals as full VMs

Not if you're doing things that require certain kernel features. For example, if I have an application that uses io_uring, it's _very_ pertinent as to which kernel it runs on. A VM has that in scope, a Docker container does not.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#87
post #80

Earlier quoted context omitted.

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

This unnecessary condescension is made all the funnier by the fact that the quote the expression alludes to wasn't actually written by Mark Twain, but in all likelihood by a French writer named Nicolas Chamfort. https://quoteinvestigator.com/2013/04/03/eat-frog/

(attempt to) being sarcastic ain't necessarily condescending. my take from the unedited parent comment was that it was patronizing towards the grandparent ("in english it is" so and so), but anyway thanks for clarification.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#88
post #80

Earlier quoted context omitted.

This unnecessary condescension is made all the funnier by the fact that the quote the expression alludes to wasn't actually written by Mark Twain, but in all likelihood by a French writer named Nicolas Chamfort. https://quoteinvestigator.com/2013/04/03/eat-frog/

(attempt to) being sarcastic ain't necessarily condescending. my take from the unedited parent comment was that it was patronizing towards the grandparent ("in english it is" so and so), but anyway thanks for clarification.

The unedited comment literally has a line above the one you mention saying:

> Eat the frog? Which language is that? The expression sounds _really cool_!

...

Re: Docker Releases Plugin for Simplified Deployments into AWS

#89
post #88

Earlier quoted context omitted.

(attempt to) being sarcastic ain't necessarily condescending. my take from the unedited parent comment was that it was patronizing towards the grandparent ("in english it is" so and so), but anyway thanks for clarification.

The unedited comment literally has a line above the one you mention saying: > Eat the frog? Which language is that? The expression sounds _really cool_! ...

well then my bad.

Re: Docker Releases Plugin for Simplified Deployments into AWS

#90
post #83
post #44

Earlier quoted context omitted.

We have a similar setup — containers managed by Fargate — and solved the issue of migrations by: 1) having our app containers include the DB migration logic 2) on container startup, “check and run migrations” before app startup, 3) the trick: acquire a lock in postgres as part of step 2, so that only one node at a time can run migrations. Migrations are run inside of a begin/commit, so with the lock we have reliable…

As I understand it, the concurrency-safe lock is built into Rails for a while. Step 3 shouldn’t be necessary. https://github.com/rails/rails/pull/22122

Ah, very nice! Our setup is on python, and because of some other dev tooling we have, it’s very easy for us to have a simple decorator function that grabs the advisory lock. We can apply that decorator to any python function, including the one that triggers our migrations. If on rails, seems like using the above link would be better.
Post reply on HN