Post History

Using Docker in a dev environment: ongoing maintenance?

I followed the [instructions to set up Docker](https://github.com/codidact/qpixel/tree/develop/docker) on my developer machine and it works great.  Sometimes, though, I run into problems after I've pulled updates or switched branches.  I don't really *understand* Docker; I just followed some instructions to get an environment that has fewer challenges than running an oft-changing platform on bare metal.  I don't feel like I really know what I'm *doing*.

Can we compile a guide to common QPixel-specific pitfalls and their remedies?  I'm not asking for a full Docker tutorial (a job for their doc), but rather a guide to how it applies *to us*.  Here are some issues I've run into:

- `git` frequently reports that `Gemfile.lock` is modified, which is often innocuous but can cause pulls to abort.  It turns out that a running Docker container was (modifying? locking?) the file in a way that `git` couldn't handle.  It appears that *sometimes* I should shut down Docker containers before pulling, but I don't have a good mental model of when.

- After dependency changes, the `uwsgi-1` container sometimes needs to be rebuilt.  When should I do this and what is the correct way to do so?  I've made note of the command `docker compose --progress=plain up --build --detach --force-recreate uwsgi` but am not sure if it is sometimes overkill?

- Sometimes, upon starting the `uwsgi-1` container, the server will hit a bunch of errors and exit.  What should my next step be -- just try to rebuild, or is there something more diagnostic that I can try first?

- The `uwsgi-1` container is configured, by default, to stop trying after three failures.  Where is that configured, if I want to change it?  (Should I want to change it?)

- Is there any harm in leaving Docker Desktop and the containers running continuously for days to weeks, through changes in branches?

(I started to draft a Wiki post instead of this question, but didn't feel I have a solid-enough foundation for how to lay it out.  If a Wiki post would be better long-term than answers to this question, it is *completely fine with me* if we create that Wiki post and just point to it from an answer here.  I also considered asking several questions instead of one, but I don't have a good sense of granularity.  If some part of this is big, I'm happy to spin it off.)