5 ms·

This would be fine if Docker wasn't literally force-fed to me over the past six years. It would be fine if their updates didn't totally fuck up my development e

This would be fine if Docker wasn't literally force-fed to me over the past six years. It would be fine if their updates didn't totally fuck up my development environment, or completely break it from time to time... it'd be okay if on MacOS you weren't forced into using the desktop application. shrug In the end I don't particularly care, I still run things like a caveman using processes, systemd units, disk images, and plan for my resource usage. I just find it mighty frustrating and think its short-sighted. Anyone who gets burned by a Desktop update (which they will, this happened to me within this last two months) isn't going to think "oh if only I paid them! Duh! Silly me." Instead it's going to seem like extortion... "Oh no! We broke your development environment! Whoopsie! If you upgrade to pro you can revert and continue working immediately!" Docker was originally "magical" and each year it becomes increasingly less "magical" I can only hope it is worth it.

frenchman99 5y ago
I'd probably pay if this is an issue for me, just like I pay for other stuff that has popups for as long as you don't pay (Sublime Text, Little Snitch, etc). You're only getting Docker for free because you help them by upgrading automatically. In fact, it's pretty cool that the only requirement is to stay up to date. Some companies make you pay to get upgrades, which is less secure in a way.
- marcosnils 5y ago
  ^ 1000% this. One of the very few open minded answers I've seen so far. Of course people will complain, specially in HN. Even though I agree Docker's communication and execution wasn't the best, I applaud them since they're trying to monetize their work in a different strategy than the standard "support plan". In the end, I really hope this ends up working for them since it'll ultimately be reflected in the quality of the product. If you ever launch a Linux version I'll be happily be a paying customer.
- guitarbill 5y ago
  If someone is using Docker professionally, maybe not a issue. I don't mind paying for software, and it could probably be expensed - although I am sure there's some cases where it isn't true or is more complicated. No, what's galling about this is that Docker is used so widely. What about open source projects using Docker? Now you have to apply for an "Open Source Plan"? Great. How does that even work with contributors if they just want to install Docker to check out the project? If a project I was working on depended on Docker, I'm not sure if I'd rather spend time figuring out how to ditch Docker vs fill out their application.
- bigmattystyles 5y ago
  In this case though I agree dockers move is a bit bait and switch but I see thing like Sublime differently. In the 90s my uncle paid for winzip and I, as a dumb teen started saying how dumb he was. He didn’t skip a beat and just said: ‘they gotta eat those people’. It always stuck with me. Now that I have income, I pay for software.
  - cyberge99 5y ago
    I paid for WinRar. :) There’s even a subreddit for it.
jayd16 5y ago
What kind of problems did you run into? I've been using it in the same time frame and I haven't really run into anything.
herdcall 5y ago
If you use Golang, check out their newly introduced "embed" using which you can embed all your files into a single binary. I used to use Docker (and Kuernetes for a short while), got frustrated and switched to Buildah/Podman for quite some time, and then now have switched to using embed. I have a Golang server with Flutter frontend interacting using GRPCWeb. Now I'm able to embed the Go server code, all the Flutter generated web code, generated Protobuf code, TLS certs, all the other resources, EVERYTHING into a SINGLE statically linked binary with no external dependences. I.e., you just run the executable and it just works. Of course it interacts with an external Redis binary but by itself it's just a single executable that can just be deployed with an scp to cloud, how much easier can you get? You do need your own orchestration mechanisms, but packaging wise it seems great. Anyone else tried this?
- GauntletWizard 5y ago
  You had me until you said TLS certs. As a SRE, I'm fully onboard with single executable deployments, but you should treat your binary as public information - don't include private material, inject it into the environment at runtime. Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)
  - herdcall 5y ago
    I have a local encryption mechanism that hides these keys from view in the binaries (say using grep or strings). And I'm not comfortable with the alternative of the certs being on the server in plain view as files; I feel having them inside the binary in an encrypted form is safer. I keep the keys and certs away from GitHub of course, so only I have them as files locally. Am I missing something?
    - n_u_l_l 5y ago
      Aside from improvements with organization and environment separation when you separate the configuration from the code (and also not having to roll your own solution), one of the security risks is that you accidentally mix up binaries. You will think that will never happen until it happens. A bigger security threat, I think, is that you have the private key both on your server and on your computer. It adds another location where you could mix up, hackers now have 2 possible attack targets, and it's more likely that your PC gets infected than your server. Either way, now, if your PC gets infected or your server gets hacked they will have the private key, while if you only have it on your server they won't necessarily have it when your PC gets infected. The safest solution if you don't want to store the private key unencrypted is to generate an encrypted private key with openssl. You would however need to provide the encryption key every time you start the server. You will still have the unencrypted private key in RAM, but that's inevitable and also the case with your current method. The private key (even encrypted) should never leave the server.

frenchman99 5y ago

I'd probably pay if this is an issue for me, just like I pay for other stuff that has popups for as long as you don't pay (Sublime Text, Little Snitch, etc). You're only getting Docker for free because you help them by upgrading automatically. In fact, it's pretty cool that the only requirement is to stay up to date. Some companies make you pay to get upgrades, which is less secure in a way.

marcosnils 5y ago
^ 1000% this. One of the very few open minded answers I've seen so far. Of course people will complain, specially in HN. Even though I agree Docker's communication and execution wasn't the best, I applaud them since they're trying to monetize their work in a different strategy than the standard "support plan". In the end, I really hope this ends up working for them since it'll ultimately be reflected in the quality of the product. If you ever launch a Linux version I'll be happily be a paying customer.
guitarbill 5y ago
If someone is using Docker professionally, maybe not a issue. I don't mind paying for software, and it could probably be expensed - although I am sure there's some cases where it isn't true or is more complicated. No, what's galling about this is that Docker is used so widely. What about open source projects using Docker? Now you have to apply for an "Open Source Plan"? Great. How does that even work with contributors if they just want to install Docker to check out the project? If a project I was working on depended on Docker, I'm not sure if I'd rather spend time figuring out how to ditch Docker vs fill out their application.
bigmattystyles 5y ago
In this case though I agree dockers move is a bit bait and switch but I see thing like Sublime differently. In the 90s my uncle paid for winzip and I, as a dumb teen started saying how dumb he was. He didn’t skip a beat and just said: ‘they gotta eat those people’. It always stuck with me. Now that I have income, I pay for software.
- cyberge99 5y ago
  I paid for WinRar. :) There’s even a subreddit for it.

jayd16 5y ago

What kind of problems did you run into? I've been using it in the same time frame and I haven't really run into anything.

herdcall 5y ago

If you use Golang, check out their newly introduced "embed" using which you can embed all your files into a single binary. I used to use Docker (and Kuernetes for a short while), got frustrated and switched to Buildah/Podman for quite some time, and then now have switched to using embed. I have a Golang server with Flutter frontend interacting using GRPCWeb. Now I'm able to embed the Go server code, all the Flutter generated web code, generated Protobuf code, TLS certs, all the other resources, EVERYTHING into a SINGLE statically linked binary with no external dependences. I.e., you just run the executable and it just works. Of course it interacts with an external Redis binary but by itself it's just a single executable that can just be deployed with an scp to cloud, how much easier can you get? You do need your own orchestration mechanisms, but packaging wise it seems great. Anyone else tried this?

GauntletWizard 5y ago
You had me until you said TLS certs. As a SRE, I'm fully onboard with single executable deployments, but you should treat your binary as public information - don't include private material, inject it into the environment at runtime. Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)
- herdcall 5y ago
  I have a local encryption mechanism that hides these keys from view in the binaries (say using grep or strings). And I'm not comfortable with the alternative of the certs being on the server in plain view as files; I feel having them inside the binary in an encrypted form is safer. I keep the keys and certs away from GitHub of course, so only I have them as files locally. Am I missing something?
  - n_u_l_l 5y ago
    Aside from improvements with organization and environment separation when you separate the configuration from the code (and also not having to roll your own solution), one of the security risks is that you accidentally mix up binaries. You will think that will never happen until it happens. A bigger security threat, I think, is that you have the private key both on your server and on your computer. It adds another location where you could mix up, hackers now have 2 possible attack targets, and it's more likely that your PC gets infected than your server. Either way, now, if your PC gets infected or your server gets hacked they will have the private key, while if you only have it on your server they won't necessarily have it when your PC gets infected. The safest solution if you don't want to store the private key unencrypted is to generate an encrypted private key with openssl. You would however need to provide the encryption key every time you start the server. You will still have the unencrypted private key in RAM, but that's inevitable and also the case with your current method. The private key (even encrypted) should never leave the server.