3 ms·

One advantage of using docker for everything is reproducibility. Your dev and prod environmentsncan be almost identical.

scarface74 4y ago
Is it really that much easier than just installing the same version of Postgres and running SQL queries to create the schema/seed the data? You’re not going to be using the same data in production and dev.
- davidatbu 4y ago
  I personally definitely find it easier to use Docker than to setup the same versions of postgres across multiple OSes, or OS versions.
- Kwpolska 4y ago
  How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the Debian/Ubuntu packages? Or I can sidestep all these questions, and just use the same Docker image everywhere, which will give me the same version of Postgres and the same config. I agree it shouldn’t contain any schema/data.
  - scarface74 4y ago
    It’s been ages since I did bare metal/VM installs of databases and then it was MySQL. But installing the database is a one time thing. The challenge was and is always syncing schema changes and loading seed data.
  - fijiaarone 4y ago
    SQL is a fairly common standard that’s been around for a few years. Postgres is an open source product that has some traction, and even if it disappears next week you still have the source. Linux is starting to catch on and you can even find places that support it. The POSIX layer is widely implemented and even Windows and Mac have sone level of support. What I’m saying is, you can choose from a wide variety of databases on pretty much any common OS and most of the features will just work on all of them. Minor versions of a single database on different flavors of the same OS are not a big deal.
    - scarface74 4y ago
      I wouldn’t go as far as say SQL is a standard. Yes there is standard SQL. But every database has its own dialect even for simple stuff like choosing a range of rows.
  - UncleEntity 4y ago
    Couldn’t you just install the server OS in a VM on the dev machine and solve all the problems?
    - davidatbu 4y ago
      That sounds like a more heavyweight[0], and much more cumbersome[1] version of using Docker. [0] Much more CPU and RAM needed. [1] You rarely work with a fresh OS install; you'll have to install things, edit files in /etc/ or whatever, set firewall rules perhaps. For me at least, many of this comes with googling, say, "how do I allow an incoming TCP connection for a port range?". Ie, tiny details I don't want to memorize. I'll have to replicate these steps between the dev VM and the prod environment. If I use Docker, I can write these things into the Dockerfile and then just do "docker-compose up" in production, and it will just work. Also, I can commit that Dockerfile into a repo. It makes it much easier for others, or future-me, to understand what the dev-ops setup is like.

scarface74 4y ago

Is it really that much easier than just installing the same version of Postgres and running SQL queries to create the schema/seed the data? You’re not going to be using the same data in production and dev.

davidatbu 4y ago
I personally definitely find it easier to use Docker than to setup the same versions of postgres across multiple OSes, or OS versions.
Kwpolska 4y ago
How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the Debian/Ubuntu packages? Or I can sidestep all these questions, and just use the same Docker image everywhere, which will give me the same version of Postgres and the same config. I agree it shouldn’t contain any schema/data.
- scarface74 4y ago
  It’s been ages since I did bare metal/VM installs of databases and then it was MySQL. But installing the database is a one time thing. The challenge was and is always syncing schema changes and loading seed data.
- fijiaarone 4y ago
  SQL is a fairly common standard that’s been around for a few years. Postgres is an open source product that has some traction, and even if it disappears next week you still have the source. Linux is starting to catch on and you can even find places that support it. The POSIX layer is widely implemented and even Windows and Mac have sone level of support. What I’m saying is, you can choose from a wide variety of databases on pretty much any common OS and most of the features will just work on all of them. Minor versions of a single database on different flavors of the same OS are not a big deal.
  - scarface74 4y ago
    I wouldn’t go as far as say SQL is a standard. Yes there is standard SQL. But every database has its own dialect even for simple stuff like choosing a range of rows.
- UncleEntity 4y ago
  Couldn’t you just install the server OS in a VM on the dev machine and solve all the problems?
  - davidatbu 4y ago
    That sounds like a more heavyweight[0], and much more cumbersome[1] version of using Docker. [0] Much more CPU and RAM needed. [1] You rarely work with a fresh OS install; you'll have to install things, edit files in /etc/ or whatever, set firewall rules perhaps. For me at least, many of this comes with googling, say, "how do I allow an incoming TCP connection for a port range?". Ie, tiny details I don't want to memorize. I'll have to replicate these steps between the dev VM and the prod environment. If I use Docker, I can write these things into the Dockerfile and then just do "docker-compose up" in production, and it will just work. Also, I can commit that Dockerfile into a repo. It makes it much easier for others, or future-me, to understand what the dev-ops setup is like.