4 ms·

It's always the shared volumes that kill you. Especially for I/O intensive stuff like npm and webpack builds. With that said if you're doing mostly backend stu

It's always the shared volumes that kill you. Especially for I/O intensive stuff like npm and webpack builds. With that said if you're doing mostly backend stuff in Go/Python/Ruby etc it's quite good. Most of my complaints are from full-stack development.

yolo3000 4y ago
Why do you use docker to build local stuff?
- ytjohn 4y ago
  Our team has pipelines that builds, runs, and tests our code in containers. We like to approximate this locally with docker compose. This helps eliminate things like forgetting to update pyproject.toml. Additionally, since the pipeline uses an internal artifactory/harbor (no external Internet), the containers we use have environment variables using the internal resources.
- spamizbad 4y ago
  Good question: we actually decided to just not do this for local "statics". But having everything containerized makes it easier to attach editor contexts, work in the same environment as your CI/CD system etc. The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.
treis 4y ago
Ruby takes forever to start the application because it has to open all the files. 4-8 minutes IIRC before the first test would run in our Rails monolith on my M1 pro.
black3r 4y ago
If you're on Mac, have you tried the VirtioFS shared volume implementation yet? It was under experimental features until recently and you need macOS 12.5 to enable them, but it's very noticeably faster for I/O intensive stuff (my webpack builds are still 2x slower than native, but I wouldn't call it utterly unusable anymore)...

4 ms·

It's always the shared volumes that kill you. Especially for I/O intensive stuff like npm and webpack builds. With that said if you're doing mostly backend stu

by spamizbad 4y ago

yolo3000 4y ago
Why do you use docker to build local stuff?
- ytjohn 4y ago
  Our team has pipelines that builds, runs, and tests our code in containers. We like to approximate this locally with docker compose. This helps eliminate things like forgetting to update pyproject.toml. Additionally, since the pipeline uses an internal artifactory/harbor (no external Internet), the containers we use have environment variables using the internal resources.
- spamizbad 4y ago
  Good question: we actually decided to just not do this for local "statics". But having everything containerized makes it easier to attach editor contexts, work in the same environment as your CI/CD system etc. The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.
treis 4y ago
Ruby takes forever to start the application because it has to open all the files. 4-8 minutes IIRC before the first test would run in our Rails monolith on my M1 pro.
black3r 4y ago
If you're on Mac, have you tried the VirtioFS shared volume implementation yet? It was under experimental features until recently and you need macOS 12.5 to enable them, but it's very noticeably faster for I/O intensive stuff (my webpack builds are still 2x slower than native, but I wouldn't call it utterly unusable anymore)...