111–120 of 158 posts
Earlier quoted context omitted.
Docker on Mac is a performance and battery hog in my experience.
It's so bad I just install a RHEL VM and use podman instead. The difference is insane.
Disclaimer: Just a fan.
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 \ -…
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.
But looking at my docker list of auxillary services for 8 projects, I see redis, postgis, postgres 10, postgres latest, memcached, mailcatcher (fake smtp), ldap, a custom oauth, kafka, MySQL, piwik(matomo), in various forms and configs.
Sure, abstraction layers and adapters keep many such dependencies out of the way in Dev and testruns. But the inevitable debugging and troubleshooting does require a quick way to run such a service.
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 \ -…
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 fro…
These days I tend to use "asdf" for my Postgres version management. It's not as friendly, but I kind of like running my services (where n < 5) in the foreground myself so I can see errors in the console with ease, and I like that asdf handles all the tools where I have exacting version requirements consistently (and even a few I don't).
For a really nice client for macOS see Postico: https://eggerapps.at/postico/ (not affiliated, just a fan)
I would recommend TablePlus as it supports more than just postgres, and is also on Windows if you need it. Not affiliated, just an extremely happy customer.
Earlier quoted context omitted.
Using docker-sync helps alot, and then using it's ability to ignore certain folders (like folders with high churn like tmp and log folders) helps even more. Over time the performance story has improved, but I still find docker-sync to be the best approach for me, and I've been 100% Docker Compose for about 4 years now (even on projects that don't deploy to Docker)
I used docker-sync for a long time, but last time I tried it (2019) it was too unreliable—I spent 30 minutes to an hour every week diagnosing issues with out of sync files and broken sync processes.
Earlier quoted context omitted.
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.
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 necess…
Earlier quoted context omitted.
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.
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 th…
That's very cool, will definitely give it a whirl!
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 \ -…
Docker on Mac is a performance and battery hog in my experience.
Earlier quoted context omitted.
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 fro…
I've run into problems bind-mounting node_modules, so I just do an install for the image. There are the performance problems you mentioned, but also sometimes libraries build differently in Linux vs. Mac.