Nice. Software developer, gamer, occasionally 3d printing, coffee lover.

  • 0 Posts
  • 27 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2023

help-circle




  • So far I’ve helped my team of 5 get on them. Some other teams are starting as well. We’ve got Windows, Linux, and Mac OSX that developers are running on their work machine (for now), and the only container specific issue we ever encounter is port conflicts, which are well documented with easy to change environment variables to control.

    The only real caveat right now is we have a bunch of micro services, and so their supporting services (redis, mariadb, etc.) end up running multiple times, so their is some performance loss from that. But they’re all designed to be independent, only talking to each other via their API, so the approach works.


  • Zikeji@programming.devtoProgrammer Humor@programming.devWorks on my machine
    link
    fedilink
    English
    arrow-up
    52
    arrow-down
    4
    ·
    2 months ago

    If this is your take your exposure has been pretty limited. While I agree some devs take it to the extreme, Docker is not a cop out. It (and similar containerization platforms) are invaluable tools.

    Using devcontainers (Docker containers in the IDE, basically) I’m able to get my team developing in a consistent environment in mere minutes, without needing to bother IT.

    Using Docker orchestration I’m able to do a lot in prod, such as automatic scaling, continuous deployment with automated testing, and in worst case near instantaneous reverts to a previously good state.

    And that’s just how I use it as a dev.

    As self hosting enthusiast I can deploy new OSS projects without stepping through a lengthy install guide listing various obscure requirements, and if I did want to skip the container (which I’ve only done a few things) I can simply read the Dockerfile to figure out what I need to do instead of hoping the install guide covers all the bases.

    And if I need to migrate to a new host? A few DNS updates and SCP/rsync later and I’m done.













  • Disagreed. If it requires a server side element, it incurs an ongoing cost and a subscription can be justified. And to clarify, by “requires”, I’m referring to the functionality, not having it shoveled in. And the price should be realistic.

    Some apps do this well, Sleep for Android is an example that comes to mind. Free with ads, ad-free is an inexpensive one time purchase. You can also purchase additional plugin apps that add functionality that isn’t required or even useful for most people. And finally, they have a cloud plugin app to let you backup your data, you can pay for their cloud subscription which is $2.99 a year, but you can also just use other cloud for storage like Google drive.


  • The Dockerfile is essentially the instructions for deploying from scratch. Sure, they most likely only exist for one distro but adapting isn’t a huge chore.

    You can also clone the repo and build the container yourself. If you want to update say, log4j, and then attempt to build it, that’s still entirely possible and easier than from scratch considering the build environment is consistent.


  • Not to mention a dead pixel can be indicative of future failures. My brand new Pixel 7 Pro had a single dead pixel. I didn’t notice until I finished setting it up (or maybe it didn’t show up until then). Being lazy and not wanting to set it up again, I decided to ignore it. It was at the bottom, out of the way.

    A month or two later I woke up one day, checked notifications and took my horror that dead pixel had upgraded to an entire line at the bottom. Enough was enough, I missed my window for a store return but was able to get a RMA setup. Replacement is going strong, no dead pixel and none showing up.