7 ms·

As someone who has not yet adopted to Docker, even though that seems to be what is done on contemporary best-in-class PaaS.... I don't totally understand the m

As someone who has not yet adopted to Docker, even though that seems to be what is done on contemporary best-in-class PaaS.... I don't totally understand the maintenance story. On heroku with buildpacks, I don't need to worry about OS-level security patches, patches to anything that was included in the base stack provided by the PaaS, they are responsible for. Which I consider part of the value proposition. When I switch to using "Docker" containers to specify my environment to the PaaS... if there is a security patch to the OS that I loaded in one of my layers... it's up to me to notice and update my container? Or what? How is this actually handled in practice? (And I agree with someone else in this thread that this fly.io series of essays on docker is _great_, it's helping me understand docker better whether or not I use fly.io!)

whazor 4y ago
The result of a Heroku build pack is also a Docker image. The switching of base layers is a feature of the docker image design, though not normally used by normal docker users.
regularfry 4y ago
The answer to that is "something that is not Docker handles it". Wherever you're hosting your images there'll be something platform-specific that handles it. Azure, AWS, and GCP all have tools that'll scan and raise a notification. If you want that to trigger an automatic rebuild, the tools are there to do it. Going from there to "I don't need to think about any CVE ever" is a bit more of a policy and opinion question.
- jrochkind1 4y ago
  I hadn't even thought I would be "hosting my images" on something like Azure, aWS, or GCP to deploy to fly.io. Their examples don't mention that. You just have a Dockerfile in your repo, you deploy to fly.io. But it sounds like for patch/update management purposes, now I need to add something like that in? Another platform/host to maintain/manage, at possibly additional price, and then we add dealing with the specific mechanisms for scanning/updating too... Bah. It remains mystifying to me that the current PaaS docker-based "best practices" involve _quite a bit_ more management than heroku. I pay for a PaaS hoping to not do this management! It seems odd to me that the market does not any longer seem to be about providing this service.
  - regularfry 4y ago
    You can run something like trivy locally, which will do that particular job. Fly.io might add that later. It is odd, but the general direction of the market (at least at the top) is becoming less opinionated, which means you need to bring your own. Not sure I like that myself.
jayd16 4y ago
I think the idea is you have a CI/CD pipeline that will periodically rebuild and redeploy with the latest base images along with your code updates and such.
mike_hearn 4y ago
Yeah the fly.io stuff is great, beautiful artwork too, top class job. Re: security updates. It's not handled. There are companies that will scan your infrastructure to figure out what's in your containers and find out of date OS base images. One thing I'm currently experimenting with is a product for people who would like an experience slightly closer to traditional Linux. The gist is, e.g. include "#!gradle -q printConveyorConfig" // Import Java server app { deploy.to = "vm-frontend-{lhr,nyc}{1-10}.somecloud.com" linux { services.server { include "/stdlib/linux/service.conf" } debian.control.Depends = "postgres (>= 14)" } } Then you run "conveyor push" from any OS and it downloads a Linux JVM, minimizes it for your app, bundles it with your JARs, produces a DEB from that, sftps it to the server, installs it using apt, that package integrates the server with systemd for startup/shutdown and dynamic users, it healthchecks the server to ensure it starts up and it can do rolling upgrades/downgrades. And of course the same for Go or NodeJS or whatever other server frameworks you like. So the idea is that if you use a portable runtime you can develop locally on macOS or Windows and not have to deal with Linux VMs, but deployment is transparent. SystemD can also run containers and "portable services", as well as using cgroups for isolation and sandboxing, so there's no need to use debs specifically. It just means that you can depend on stuff that will get upgraded as part of whole OS system upgrades. We use this to maintain our own servers and it's quite nice. One of the things that always bugged me about Linux is that deploying servers to it always looks like either "sftp a tarball and then wire things up yourself using vim", or Docker which involves registries and daemons and isolated OS images, but there's nothing in between. Not sure whether it's worth releasing though. Docker seems so dominant.
- jrochkind1 4y ago
  > It's not handled. So... what do actual real people do in practice? I am very confused what people are actually doing here. LOTS of people seem to have moved to this kind of docker-based deploy for PaaS. They can't all just be... ignoring security patches? I am very confused that nobody else seems to think the "handle patches story" is a big barrier to moving from heroku-style to docker-style... that everyone else just moves to docker-style? What are they actually doing to deal with patches? I admit I don't really understand your solution -- I am not a sysadmin! This is why we deploy to heroku and pay them to take care of it! It is confusing to me that none of the other PaaS competitors to heroku -- including fly.io -- seem to think this is something their customers might want...
bvirb 4y ago
Same boat here. I'm doubtful that we could take on the additional maintenance work for less than the Heroku premium we pay. I wouldn't be surprised if I'm wrong and newer tools bridge the gap for a lower price and/or time investment, but I also wouldn't be surprised if I'm right and many places using Docker could save time/money offloading the maintenance to something more like a managed PaaS.
- jrochkind1 4y ago
  Agreed. I actually have not too much problem with heroku pricing (I could complain about some areas, but it's working for us) -- I'm just worried that heroku seems to be slowly disintegrating through lack of investment, so am worried that there seem to be no other realistic options for that level of service! There don't seem to be other reliable options for managed PaaS that takes care of maintenance in the same way.
  - subarctic 4y ago
    I've seen render.com thrown around a bit as an alternative. Haven't tried it out myself though. There's also netlify, vercel and similar sites but I think they're mainly geared toward all-javascript apps.
ehhthing 4y ago
For what it's worth, the vast majority of vulns in a web app are in its code or dependencies rather than in the base OS. I haven't actually seen any real-world cases of getting hacked because your docker base OS image was out of date. The only exception I would give would be for like language runtime version, which can occasionally be an attack vector. Switching runtime version usually requires manual testing regardless, so I wouldn't really consider it a docker-only problem. If you're really concerned, just have a CI job that rebuilds and tests with newer base image versions.

whazor 4y ago

The result of a Heroku build pack is also a Docker image. The switching of base layers is a feature of the docker image design, though not normally used by normal docker users.

regularfry 4y ago

The answer to that is "something that is not Docker handles it". Wherever you're hosting your images there'll be something platform-specific that handles it. Azure, AWS, and GCP all have tools that'll scan and raise a notification. If you want that to trigger an automatic rebuild, the tools are there to do it. Going from there to "I don't need to think about any CVE ever" is a bit more of a policy and opinion question.

jrochkind1 4y ago
I hadn't even thought I would be "hosting my images" on something like Azure, aWS, or GCP to deploy to fly.io. Their examples don't mention that. You just have a Dockerfile in your repo, you deploy to fly.io. But it sounds like for patch/update management purposes, now I need to add something like that in? Another platform/host to maintain/manage, at possibly additional price, and then we add dealing with the specific mechanisms for scanning/updating too... Bah. It remains mystifying to me that the current PaaS docker-based "best practices" involve _quite a bit_ more management than heroku. I pay for a PaaS hoping to not do this management! It seems odd to me that the market does not any longer seem to be about providing this service.
- regularfry 4y ago
  You can run something like trivy locally, which will do that particular job. Fly.io might add that later. It is odd, but the general direction of the market (at least at the top) is becoming less opinionated, which means you need to bring your own. Not sure I like that myself.

jayd16 4y ago

I think the idea is you have a CI/CD pipeline that will periodically rebuild and redeploy with the latest base images along with your code updates and such.

mike_hearn 4y ago

Yeah the fly.io stuff is great, beautiful artwork too, top class job. Re: security updates. It's not handled. There are companies that will scan your infrastructure to figure out what's in your containers and find out of date OS base images. One thing I'm currently experimenting with is a product for people who would like an experience slightly closer to traditional Linux. The gist is, e.g. include "#!gradle -q printConveyorConfig" // Import Java server app { deploy.to = "vm-frontend-{lhr,nyc}{1-10}.somecloud.com" linux { services.server { include "/stdlib/linux/service.conf" } debian.control.Depends = "postgres (>= 14)" } } Then you run "conveyor push" from any OS and it downloads a Linux JVM, minimizes it for your app, bundles it with your JARs, produces a DEB from that, sftps it to the server, installs it using apt, that package integrates the server with systemd for startup/shutdown and dynamic users, it healthchecks the server to ensure it starts up and it can do rolling upgrades/downgrades. And of course the same for Go or NodeJS or whatever other server frameworks you like. So the idea is that if you use a portable runtime you can develop locally on macOS or Windows and not have to deal with Linux VMs, but deployment is transparent. SystemD can also run containers and "portable services", as well as using cgroups for isolation and sandboxing, so there's no need to use debs specifically. It just means that you can depend on stuff that will get upgraded as part of whole OS system upgrades. We use this to maintain our own servers and it's quite nice. One of the things that always bugged me about Linux is that deploying servers to it always looks like either "sftp a tarball and then wire things up yourself using vim", or Docker which involves registries and daemons and isolated OS images, but there's nothing in between. Not sure whether it's worth releasing though. Docker seems so dominant.

jrochkind1 4y ago
> It's not handled. So... what do actual real people do in practice? I am very confused what people are actually doing here. LOTS of people seem to have moved to this kind of docker-based deploy for PaaS. They can't all just be... ignoring security patches? I am very confused that nobody else seems to think the "handle patches story" is a big barrier to moving from heroku-style to docker-style... that everyone else just moves to docker-style? What are they actually doing to deal with patches? I admit I don't really understand your solution -- I am not a sysadmin! This is why we deploy to heroku and pay them to take care of it! It is confusing to me that none of the other PaaS competitors to heroku -- including fly.io -- seem to think this is something their customers might want...

bvirb 4y ago

Same boat here. I'm doubtful that we could take on the additional maintenance work for less than the Heroku premium we pay. I wouldn't be surprised if I'm wrong and newer tools bridge the gap for a lower price and/or time investment, but I also wouldn't be surprised if I'm right and many places using Docker could save time/money offloading the maintenance to something more like a managed PaaS.

jrochkind1 4y ago
Agreed. I actually have not too much problem with heroku pricing (I could complain about some areas, but it's working for us) -- I'm just worried that heroku seems to be slowly disintegrating through lack of investment, so am worried that there seem to be no other realistic options for that level of service! There don't seem to be other reliable options for managed PaaS that takes care of maintenance in the same way.
- subarctic 4y ago
  I've seen render.com thrown around a bit as an alternative. Haven't tried it out myself though. There's also netlify, vercel and similar sites but I think they're mainly geared toward all-javascript apps.

ehhthing 4y ago

For what it's worth, the vast majority of vulns in a web app are in its code or dependencies rather than in the base OS. I haven't actually seen any real-world cases of getting hacked because your docker base OS image was out of date. The only exception I would give would be for like language runtime version, which can occasionally be an attack vector. Switching runtime version usually requires manual testing regardless, so I wouldn't really consider it a docker-only problem. If you're really concerned, just have a CI job that rebuilds and tests with newer base image versions.