6 ms·

Instead of doing all of that, you could also do it without docker. Simply install postgres via your Linux distro and run e.g.: /usr/lib/postgresql/9.5/bin/

by nh2 9y ago

Instead of doing all of that, you could also do it without docker. Simply install postgres via your Linux distro and run e.g.: /usr/lib/postgresql/9.5/bin/postgres -D .mydatadir

bschwindHN 9y ago
Sure you can do that, but if your app needs to use other services (Redis, for example) you can easily throw that in the compose file as well, and then it's easy to maintain versions and have every developer be on the same page. This is especially helpful if some developers use OS X or Windows. I don't understand the "all of that" phrasing, as if what I just described was a large amount of work.
- hasenj 9y ago
  Why would I want to use redis? My whole point is that I want to simplify my setup, so that I don't need tons of third party servers.
  - bschwindHN 9y ago
    Do you reimplement caching and data storage on every new project? Redis is just one example. Surely in any major project you've made use of a third party server? Maybe not, but tons of projects do and I'm simply describing an easy way to manage those services in a development environment. What's so hard to understand about this?
- ComputerGuru 9y ago
  How many people run webwpps with changing version requirements for their _database_? Docker is useful for running components of your own code or for isolation, not for managing versions of core applications like a database or a mail server for most people deploying ready-made apps.
  - bschwindHN 9y ago
    Different web apps may use differing DB versions, it happens. I'm merely suggesting docker compose is a fairly simple way to handle this without managing global installations on a dev machine. Keep in mind this is for local development only, I wouldn't use a docker hosted DB in production though you certainly could if you wanted to. I've tried several different dev environment setups and this approach yields the fewest frustrations and inconsistencies. Production is a different story but that's not what I'm discussing here.
    - ComputerGuru 9y ago
      I'm not trying to beat a dead horse here, but what kind of app runs on a database version 5 but not version 6 (for example)? I can see an app relying on features not available in older releases, but databases - of all software - have rock-solid backwards compatibility.
      - bschwindHN 9y ago
        I mean yeah, changing DB minor versions probably won't affect anything, perhaps even changing major versions is alright in most cases. To me, the value is in reducing the number of potential issues a developer can have in their environment and making the build and runtime as consistent as possible. And when the solution is so easy to use, I don't see much of a downside to the docker approach. My team switched from Vagrant to docker compose for our development environments and since then we've had much more stability and have wasted much less time tending to them.
  - lobster_johnson 9y ago
    Running a database in Docker is useful if you think more broadly of containers and orchestration, and think less about nodes and more about the cluster as a pool of resources. All our "system software" — Postgres, Redis, Memcached, RabbitMQ, Elasticsearch, etc. — run as containers on Kubernetes. Doing so allows us to start new versions without considering the host OS. For example, we can upgrade Postgres to a new release the moment it's out, without having to wait for Debian or Ubuntu or whatever. It also allows us to run different versions (e.g. a new one for testing in our "staging" environment) concurrently without any concerns about which node is running what. In fact, almost nothing needs to be configured with information about "nodes"; everything is routed to the right place, and the client only needs a name to connect to. Sometimes we start temporary instances of software, e.g. to experiment with. Bring the container up, do the testing, bring container down; nothing ever got installed on the host OS.

by nh2 9y ago

Instead of doing all of that, you could also do it without docker. Simply install postgres via your Linux distro and run e.g.: /usr/lib/postgresql/9.5/bin/postgres -D .mydatadir

bschwindHN 9y ago

Sure you can do that, but if your app needs to use other services (Redis, for example) you can easily throw that in the compose file as well, and then it's easy to maintain versions and have every developer be on the same page. This is especially helpful if some developers use OS X or Windows. I don't understand the "all of that" phrasing, as if what I just described was a large amount of work.

hasenj 9y ago
Why would I want to use redis? My whole point is that I want to simplify my setup, so that I don't need tons of third party servers.
- bschwindHN 9y ago
  Do you reimplement caching and data storage on every new project? Redis is just one example. Surely in any major project you've made use of a third party server? Maybe not, but tons of projects do and I'm simply describing an easy way to manage those services in a development environment. What's so hard to understand about this?
ComputerGuru 9y ago
How many people run webwpps with changing version requirements for their _database_? Docker is useful for running components of your own code or for isolation, not for managing versions of core applications like a database or a mail server for most people deploying ready-made apps.
- bschwindHN 9y ago
  Different web apps may use differing DB versions, it happens. I'm merely suggesting docker compose is a fairly simple way to handle this without managing global installations on a dev machine. Keep in mind this is for local development only, I wouldn't use a docker hosted DB in production though you certainly could if you wanted to. I've tried several different dev environment setups and this approach yields the fewest frustrations and inconsistencies. Production is a different story but that's not what I'm discussing here.
  - ComputerGuru 9y ago
    I'm not trying to beat a dead horse here, but what kind of app runs on a database version 5 but not version 6 (for example)? I can see an app relying on features not available in older releases, but databases - of all software - have rock-solid backwards compatibility.
    - bschwindHN 9y ago
      I mean yeah, changing DB minor versions probably won't affect anything, perhaps even changing major versions is alright in most cases. To me, the value is in reducing the number of potential issues a developer can have in their environment and making the build and runtime as consistent as possible. And when the solution is so easy to use, I don't see much of a downside to the docker approach. My team switched from Vagrant to docker compose for our development environments and since then we've had much more stability and have wasted much less time tending to them.
- lobster_johnson 9y ago
  Running a database in Docker is useful if you think more broadly of containers and orchestration, and think less about nodes and more about the cluster as a pool of resources. All our "system software" — Postgres, Redis, Memcached, RabbitMQ, Elasticsearch, etc. — run as containers on Kubernetes. Doing so allows us to start new versions without considering the host OS. For example, we can upgrade Postgres to a new release the moment it's out, without having to wait for Debian or Ubuntu or whatever. It also allows us to run different versions (e.g. a new one for testing in our "staging" environment) concurrently without any concerns about which node is running what. In fact, almost nothing needs to be configured with information about "nodes"; everything is routed to the right place, and the client only needs a name to connect to. Sometimes we start temporary instances of software, e.g. to experiment with. Bring the container up, do the testing, bring container down; nothing ever got installed on the host OS.