6 ms·

I've always preferred Docker for setting up databases and database-like services on a development machine because then everything is nicely isolated. i.e no nee

I've always preferred Docker for setting up databases and database-like services on a development machine because then everything is nicely isolated. i.e no need to worry about random files in /etc/foo, easy to setup many versions per project etc. This is what I've been using for Postgres: docker volume create postgres docker run -d \ -p 127.0.0.1:5432:5432 \ -v postgres:/var/lib/postgresql/data \ --name postgres \ --restart always \ postgres (this one is just latest, but adding a version is trivial)

Doctor_Fegg 5y ago
Postgres.app supports multiple versions, and doesn't put random files in /etc/foo - everything is in the right place for a Mac app, i.e. Postgres itself is in /Applications and the database is in ~/Library/Application\ Support/Postgres.
- Trufa 5y ago
  That's interesting, but my situation is that I'm developing on macOS and deploying on a linux box so my postgres setup with docker can look virtually identical.
  - mromanuk 5y ago
    Why worry about one more level of abstraction, if using the same version of Postgres should be enough?
    - Igelau 5y ago
      > if using the same version of Postgres should be enough
    - handrous 5y ago
      If you're using Docker on the server, too, then it saves you from dealing with package management & version availability across multiple operating systems or distros to ensure that everything's at the same version no matter where it is. Config also looks very similar and lives in a consistent location regardless of the platform, which is nice, and between the docker file and either the startup command or the docker-compose file, you've also got documentation for exactly where any important data for the dockerized service lives and can easily prove that you've located all the important data (destroy the container, bring it back up... still looks good, no data loss? Then it's all documented). Again, with a single tool, regardless of platform. No one has to give any shits that Fred's workstation runs the latest Ubuntu and Sally likes Arch and John is on macOS and the server is Debian Stable. They'll all run the same versions of your project's service dependencies... and the correct versions of the other five projects you're all working on, which don't need to be updated in lock-step, and Amy the part-time remote contractor you just brought on doesn't have to have her machine polluted with actual installs of any dependencies for your project outside the repo itself, just easily-eradicated containers.
moonchrome 5y ago
Docker on Mac is a performance and battery hog in my experience.
- Aeolun 5y ago
  It also keeps yammering on and on about new versions and required updates. Just that is reason enough to get rid of it.
  - oauea 5y ago
    "Oh no, I have to update my software!" Are you serious?
    - canadianfella 5y ago
      Why would you doubt the seriousness?
    - rubyist5eva 5y ago
      Docker is notorious for completely breaking everything with their updates. They are also very intrusive about it, and make ignoring updates a paid feature. This isn't just a "i don't want to update" issue. It's a "docker is terrible software and their business model is just as terrible".
      - oauea 5y ago
        Literally never had anything break due to upgrades in the ~7 years I've used docker (on Linux), but ok. Do you have any examples? They renamed some packages a few times but no big deal, just uninstall the old ones and reinstall the new ones and everything's back up & running with all data kept. The worst thing was when they switched from aufs to overlay2 but that was years ago.
        rubyist5eva 5y ago
        Countless examples of automatic updates borking installs on the github issue tracker.
nightpool 5y ago
I love using Docker Compose in theory, but I've found it really difficult to do local development with a "Docker only" setup on Mac, due to the performance issues with the filesystem layer (even when using cached volumes, etc). Ruby gemfiles and node_modules are big culprits here, since they involve a lot of filesystem accesses to load/install dependencies. It might be more manageable if I was just using Postgres from docker and had e.g. rubyenv and nodenv installed locally, but that sacrifices a lot of the benefits you gain from having a docker-compose setup, and I've never had any problems with managing multiple PG versions in my Postgres.app install.
- Kaze404 5y ago
  You could look into Nix for Ruby and Nodejs. I'm not a particularly experienced Ruby developer, but having Nix take care of all versioning and dependencies for me made the whole ecosystem really accessible (in the sense that I don't need to care about most of it). Everything is still in your filesystem so there shouldn't be any performance issues, and you still get the isolation benefits from Docker (like versions and dependencies not leaking from one project to another).
  - lpasselin 5y ago
    You mean Nix as a base image?
    - Kaze404 5y ago
      No, Nix installed in your system.
      - lpasselin 5y ago
        I don't know much about Nix. But is there really any isolation if it's installed on your host os? I always thought Nix was primarily a package management tool. Like brew? Docker isolation is different.
        5y ago
bob1029 5y ago
> because then everything is nicely isolated This is why we use SQLite for all the things. I don't even remember what a database installation process looks like anymore. It's just a nuget dependency and some code for us.
- joshmarlow 5y ago
  Are you using SQLite in production too? I'm curious about your domain - is it a web application or something else?
  - bob1029 5y ago
    We do use it in production. Have been for years. We use it as part of the back-end of a business workflow automation system. Handles 100-1000 concurrent users without any issues.
    - joshmarlow 5y ago
      Thanks for the details. I would be afraid to use SQLite over Postgres as SQLite is much more... flexible with it's database constraints (or at least, this used to be the case). Not knocking your engineering choices - if you've been running it in prod for years, then it's working for you - just interested. Do you lean into DB constraints much or do you do more application level checking/enforcement?
      - scns 5y ago
        Not parent but mentioning nuget suggest parent is on dotnet, ie C/F# ergo semi-/typesafe. Parsing (not validating) at the edges should take care of it.
        bob1029 5y ago
        > Parsing (not validating) at the edges should take care of it. Precisely. We use a tiny ORM on top of Dapper to make sure everything goes in and out of columns as expected.
ramraj07 5y ago
I’m yet to see people who use docker for development do it faster than People who don’t. They always end up having to mount specific folders etc which nullifies the isolAtion point and you lose so much because even something as simple as ide debugging becomes a complicated (if not impossible) task.
- Kaze404 5y ago
  You don't have to use Docker for everything. I personally use Docker for services my application needs (Docker, Redis, etc) and Nix for the application itself.
  - handrous 5y ago
    I do something similar (minus the Nix part). I don't bother to dockerize my applications, but I use Docker as a cross-platform dependency manager for daemons they use. Before that, I used Vagrant with a full VM, which has the benefit of looking more like a provisioning script for a full server, but the down-side of being tied to whatever OS or distro you choose for the VM. Either way, it's a way to document exactly how to get your dependencies in order and the project running. That's a big improvement, operationally, at a lot of places. If Docker died tomorrow with no replacement, I'd go back to the Vagrant thing. Installing that stuff directly on my workstation sucks, for a bunch of reasons, and I'll not go back to that if I have any way to avoid it.
- Mehdi2277 5y ago
  I've spent far too much time with build errors for environment issues that I do prefer docker or other environment management tools. I just have an alias for mounting relevant folders and value of docker is not isolation for my code, but isolation for system libraries. A good example is recent mac update to big sur broke pip/python installs for a lot of people. Spending a while reading github issues to make something as basic as python and pip install numpy work is why I like docker for dev environments. There are IDEs that support docker extensions well. I also do run most of my workloads on clusters so having things dockerized makes it much easier to reproduce a failure locally. Our CI that currently isn't dockerized occasionally has environment issues that are quite annoying to debug as I lack a good way to explore it's environment and see the mismatch.
afavour 5y ago
I went down this road for a long time and eventually realised I was gaining very little from it and picking up a bunch of downsides. Obviously everyone’s experience is different because we’re all doing different things but I mostly work with Rust and Node, I use Postgres.app as a local dev database and just run the code natively, sometimes Node via nvm when I care about specific runtime versions. It works great. It performs better then any Docker-based solution (I’m on a Mac) and doesn’t leave me with a bunch of weird dangling images/containers/whatever taking up resources. I still like the idea of using the same Docker environment in dev that I use in production but in reality I just don’t need it.
- deleted 5y ago
  [deleted]
- brian_herman 5y ago
  I love docker I just get really confused when the networking gets involved in the mix. Like I tried to make a airflow cluster with docker and I gave up.
  - derefr 5y ago
    I’ve been burned by using Docker’s networking directly too many times to count, especially in the context of Docker for Mac (where “the host” sometimes means “your computer”, while other times meaning “the VM Docker runs in”, arbitrarily.) However, Kubernetes on Docker (microk8s or whatever it’s called) has always been extremely predictable in its (development-time, single-node) networking behaviour for me. Set up the right Deployment + Service + Ingress resources, ask kubectl(1) for the external IP and port to talk to, curl it—just works. Does the same externally-observable thing on your workstation that it does in prod. Of course, that requires you to learn Kubernetes… which is a much bigger pain than it should be. But once you've got it, it's pretty simple/lightweight to wield Kubernetes at a problem; and the results are much more widely-applicable to everywhere you'd want to deply than e.g. Docker Compose is.
    - BossingAround 5y ago
EamonnMR 5y ago
While Postgres works fine on macs, being able to run MySQL in a docker container and not have to deal with actually keeping it running on our macs has been a huge time saver.
devoutsalsa 5y ago
On a Mac, I like using DBngin until I need something fancier... https://dbngin.com/ https://dbngin.com/
NelsonMinar 5y ago
Let's see... the user could download an app, click it, and run Postgres. Or they could figure out how to install Docker, then run a terminal, then type two obscure and inscrutable commands into it. Perhaps administrator privileges are required along the way. Sure, the Docker route is better in many ways. But perhaps you're not understanding the audience for a packaged Mac application.
- bdcravens 5y ago
  I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. If someone finds terminal commands "obscure", I'd hate to see what their SQL looks like, in which case maybe they shouldn't be running a database server. For what it's worth, installing Docker on Mac (the audience we're talking about) is as easy as installing Postgres.app (download an installer and open). No administrator privileges necessary, unless you have a weird setup, in which case you'll run into the same issues running Postgres.app.
  - systemvoltage 5y ago
    As a software engineer with significant experience with Docker, I love the Postgres.app for local dev precisely because of 1-2 click. I also run Postgres in Docker when I need to isolate something but for most general purpose database work - I just use the Postgres app.
  - crazygringo 5y ago
    > I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. Huh? Nobody said everyone using a Mac needs it. Where did you get that from? You seem to be putting words into GP's mouth. But some people certainly could prefer it, which is the whole point of it existing, for those people. Also, your comparison isn't even close to equivalent. It's not the ease of installing Docker vs Postgres.app... it's the ease of installing Docker and then figuring out how to configure an instance with Postgres vs Postgres.app. Obviously Postgres.app is easier. Some people have no need or desire to figure out Docker, they just want to use tools installed locally.
WhyNotHugo 5y ago
Yeah, same. I usually use docker-compose per-project and manage the database (and other services) using that. The idea of a "system" postgres is kinda wierd, since that single instance has to work with all my projects -- which might have conflicting needs.
SkyMarshal 5y ago
Doesn't the OS X .app format package everything in a nicely isolated single file too? That's what it seems postgres.app does.
Macha 5y ago
I use docker (well, podman) for postgres on my personal machine because it's the one package that causes me headaches in my rolling release distro. Postgres n -> n+1 always requires a migration process (and you can't shortcut n -> n+x), so if I spend a period of time not working on my Postgres using projects, I find I've updated from n -> n+2 or more and need to figure out how to get the old version installed again since it's a dependency of the migration tools to have both versions available.
mekster 5y ago
I trust OS packages for main daemons like database, smtp, http daemons. How are you meant to apply only security patches on docker containers? What's the point of "isolating" daemons to avoid "random" files in /etc? It just makes it harder to git control and back up /etc by splitting it all over the containers.

Doctor_Fegg 5y ago

Postgres.app supports multiple versions, and doesn't put random files in /etc/foo - everything is in the right place for a Mac app, i.e. Postgres itself is in /Applications and the database is in ~/Library/Application\ Support/Postgres.

Trufa 5y ago
That's interesting, but my situation is that I'm developing on macOS and deploying on a linux box so my postgres setup with docker can look virtually identical.
- mromanuk 5y ago
  Why worry about one more level of abstraction, if using the same version of Postgres should be enough?
  - Igelau 5y ago
    > if using the same version of Postgres should be enough
  - handrous 5y ago
    If you're using Docker on the server, too, then it saves you from dealing with package management & version availability across multiple operating systems or distros to ensure that everything's at the same version no matter where it is. Config also looks very similar and lives in a consistent location regardless of the platform, which is nice, and between the docker file and either the startup command or the docker-compose file, you've also got documentation for exactly where any important data for the dockerized service lives and can easily prove that you've located all the important data (destroy the container, bring it back up... still looks good, no data loss? Then it's all documented). Again, with a single tool, regardless of platform. No one has to give any shits that Fred's workstation runs the latest Ubuntu and Sally likes Arch and John is on macOS and the server is Debian Stable. They'll all run the same versions of your project's service dependencies... and the correct versions of the other five projects you're all working on, which don't need to be updated in lock-step, and Amy the part-time remote contractor you just brought on doesn't have to have her machine polluted with actual installs of any dependencies for your project outside the repo itself, just easily-eradicated containers.

moonchrome 5y ago

Docker on Mac is a performance and battery hog in my experience.

Aeolun 5y ago
It also keeps yammering on and on about new versions and required updates. Just that is reason enough to get rid of it.
- oauea 5y ago
  "Oh no, I have to update my software!" Are you serious?
  - canadianfella 5y ago
    Why would you doubt the seriousness?
  - rubyist5eva 5y ago
    Docker is notorious for completely breaking everything with their updates. They are also very intrusive about it, and make ignoring updates a paid feature. This isn't just a "i don't want to update" issue. It's a "docker is terrible software and their business model is just as terrible".
    - oauea 5y ago
      Literally never had anything break due to upgrades in the ~7 years I've used docker (on Linux), but ok. Do you have any examples? They renamed some packages a few times but no big deal, just uninstall the old ones and reinstall the new ones and everything's back up & running with all data kept. The worst thing was when they switched from aufs to overlay2 but that was years ago.
      - rubyist5eva 5y ago
        Countless examples of automatic updates borking installs on the github issue tracker.

nightpool 5y ago

I love using Docker Compose in theory, but I've found it really difficult to do local development with a "Docker only" setup on Mac, due to the performance issues with the filesystem layer (even when using cached volumes, etc). Ruby gemfiles and node_modules are big culprits here, since they involve a lot of filesystem accesses to load/install dependencies. It might be more manageable if I was just using Postgres from docker and had e.g. rubyenv and nodenv installed locally, but that sacrifices a lot of the benefits you gain from having a docker-compose setup, and I've never had any problems with managing multiple PG versions in my Postgres.app install.

Kaze404 5y ago
You could look into Nix for Ruby and Nodejs. I'm not a particularly experienced Ruby developer, but having Nix take care of all versioning and dependencies for me made the whole ecosystem really accessible (in the sense that I don't need to care about most of it). Everything is still in your filesystem so there shouldn't be any performance issues, and you still get the isolation benefits from Docker (like versions and dependencies not leaking from one project to another).
- lpasselin 5y ago
  You mean Nix as a base image?
  - Kaze404 5y ago
    No, Nix installed in your system.
    - lpasselin 5y ago
      I don't know much about Nix. But is there really any isolation if it's installed on your host os? I always thought Nix was primarily a package management tool. Like brew? Docker isolation is different.
      - 5y ago

bob1029 5y ago

> because then everything is nicely isolated This is why we use SQLite for all the things. I don't even remember what a database installation process looks like anymore. It's just a nuget dependency and some code for us.

joshmarlow 5y ago
Are you using SQLite in production too? I'm curious about your domain - is it a web application or something else?
- bob1029 5y ago
  We do use it in production. Have been for years. We use it as part of the back-end of a business workflow automation system. Handles 100-1000 concurrent users without any issues.
  - joshmarlow 5y ago
    Thanks for the details. I would be afraid to use SQLite over Postgres as SQLite is much more... flexible with it's database constraints (or at least, this used to be the case). Not knocking your engineering choices - if you've been running it in prod for years, then it's working for you - just interested. Do you lean into DB constraints much or do you do more application level checking/enforcement?
    - scns 5y ago
      Not parent but mentioning nuget suggest parent is on dotnet, ie C/F# ergo semi-/typesafe. Parsing (not validating) at the edges should take care of it.
      - bob1029 5y ago
        > Parsing (not validating) at the edges should take care of it. Precisely. We use a tiny ORM on top of Dapper to make sure everything goes in and out of columns as expected.

ramraj07 5y ago

I’m yet to see people who use docker for development do it faster than People who don’t. They always end up having to mount specific folders etc which nullifies the isolAtion point and you lose so much because even something as simple as ide debugging becomes a complicated (if not impossible) task.

Kaze404 5y ago
You don't have to use Docker for everything. I personally use Docker for services my application needs (Docker, Redis, etc) and Nix for the application itself.
- handrous 5y ago
  I do something similar (minus the Nix part). I don't bother to dockerize my applications, but I use Docker as a cross-platform dependency manager for daemons they use. Before that, I used Vagrant with a full VM, which has the benefit of looking more like a provisioning script for a full server, but the down-side of being tied to whatever OS or distro you choose for the VM. Either way, it's a way to document exactly how to get your dependencies in order and the project running. That's a big improvement, operationally, at a lot of places. If Docker died tomorrow with no replacement, I'd go back to the Vagrant thing. Installing that stuff directly on my workstation sucks, for a bunch of reasons, and I'll not go back to that if I have any way to avoid it.
Mehdi2277 5y ago
I've spent far too much time with build errors for environment issues that I do prefer docker or other environment management tools. I just have an alias for mounting relevant folders and value of docker is not isolation for my code, but isolation for system libraries. A good example is recent mac update to big sur broke pip/python installs for a lot of people. Spending a while reading github issues to make something as basic as python and pip install numpy work is why I like docker for dev environments. There are IDEs that support docker extensions well. I also do run most of my workloads on clusters so having things dockerized makes it much easier to reproduce a failure locally. Our CI that currently isn't dockerized occasionally has environment issues that are quite annoying to debug as I lack a good way to explore it's environment and see the mismatch.

afavour 5y ago

I went down this road for a long time and eventually realised I was gaining very little from it and picking up a bunch of downsides. Obviously everyone’s experience is different because we’re all doing different things but I mostly work with Rust and Node, I use Postgres.app as a local dev database and just run the code natively, sometimes Node via nvm when I care about specific runtime versions. It works great. It performs better then any Docker-based solution (I’m on a Mac) and doesn’t leave me with a bunch of weird dangling images/containers/whatever taking up resources. I still like the idea of using the same Docker environment in dev that I use in production but in reality I just don’t need it.

deleted 5y ago
[deleted]
brian_herman 5y ago
I love docker I just get really confused when the networking gets involved in the mix. Like I tried to make a airflow cluster with docker and I gave up.
- derefr 5y ago
  I’ve been burned by using Docker’s networking directly too many times to count, especially in the context of Docker for Mac (where “the host” sometimes means “your computer”, while other times meaning “the VM Docker runs in”, arbitrarily.) However, Kubernetes on Docker (microk8s or whatever it’s called) has always been extremely predictable in its (development-time, single-node) networking behaviour for me. Set up the right Deployment + Service + Ingress resources, ask kubectl(1) for the external IP and port to talk to, curl it—just works. Does the same externally-observable thing on your workstation that it does in prod. Of course, that requires you to learn Kubernetes… which is a much bigger pain than it should be. But once you've got it, it's pretty simple/lightweight to wield Kubernetes at a problem; and the results are much more widely-applicable to everywhere you'd want to deply than e.g. Docker Compose is.
  - BossingAround 5y ago

EamonnMR 5y ago

While Postgres works fine on macs, being able to run MySQL in a docker container and not have to deal with actually keeping it running on our macs has been a huge time saver.

devoutsalsa 5y ago

On a Mac, I like using DBngin until I need something fancier... https://dbngin.com/ https://dbngin.com/

NelsonMinar 5y ago

Let's see... the user could download an app, click it, and run Postgres. Or they could figure out how to install Docker, then run a terminal, then type two obscure and inscrutable commands into it. Perhaps administrator privileges are required along the way. Sure, the Docker route is better in many ways. But perhaps you're not understanding the audience for a packaged Mac application.

bdcravens 5y ago
I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. If someone finds terminal commands "obscure", I'd hate to see what their SQL looks like, in which case maybe they shouldn't be running a database server. For what it's worth, installing Docker on Mac (the audience we're talking about) is as easy as installing Postgres.app (download an installer and open). No administrator privileges necessary, unless you have a weird setup, in which case you'll run into the same issues running Postgres.app.
- systemvoltage 5y ago
  As a software engineer with significant experience with Docker, I love the Postgres.app for local dev precisely because of 1-2 click. I also run Postgres in Docker when I need to isolate something but for most general purpose database work - I just use the Postgres app.
- crazygringo 5y ago
  > I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. Huh? Nobody said everyone using a Mac needs it. Where did you get that from? You seem to be putting words into GP's mouth. But some people certainly could prefer it, which is the whole point of it existing, for those people. Also, your comparison isn't even close to equivalent. It's not the ease of installing Docker vs Postgres.app... it's the ease of installing Docker and then figuring out how to configure an instance with Postgres vs Postgres.app. Obviously Postgres.app is easier. Some people have no need or desire to figure out Docker, they just want to use tools installed locally.

WhyNotHugo 5y ago

Yeah, same. I usually use docker-compose per-project and manage the database (and other services) using that. The idea of a "system" postgres is kinda wierd, since that single instance has to work with all my projects -- which might have conflicting needs.

SkyMarshal 5y ago

Doesn't the OS X .app format package everything in a nicely isolated single file too? That's what it seems postgres.app does.

Macha 5y ago

I use docker (well, podman) for postgres on my personal machine because it's the one package that causes me headaches in my rolling release distro. Postgres n -> n+1 always requires a migration process (and you can't shortcut n -> n+x), so if I spend a period of time not working on my Postgres using projects, I find I've updated from n -> n+2 or more and need to figure out how to get the old version installed again since it's a dependency of the migration tools to have both versions available.

mekster 5y ago

I trust OS packages for main daemons like database, smtp, http daemons. How are you meant to apply only security patches on docker containers? What's the point of "isolating" daemons to avoid "random" files in /etc? It just makes it harder to git control and back up /etc by splitting it all over the containers.