11–20 of 85 posts
Nice collection, although I don't really like binding volumes to host directories, because then you can't really use docker over SSH. I'm working on my own similar project here that exclusively uses docker named volumes: https://github.com/enigmaCurry/d.rymcg.tech
Nice collection, although I don't really like binding volumes to host directories, because then you can't really use docker over SSH. I'm working on my own similar project here that exclusively uses docker named volumes: https://github.com/enigmaCurry/d.rymcg.tech
What do you mean by "can't really use docker over SSH"? I'm not sure what that means, or how it's related to bind mounts.
If you tell me to run
docker run -v ${HOME}/stuff:/stuff alpine
There's a lot of "tool" selections in that repo. If anyone is looking for ready to go web app examples aimed at both development and production with Docker Compose, I maintain: - https://github.com/nickjj/docker-flask-example - https://github.com/nickjj/docker-rails-example - https://github.com/nickjj/docker-django-example - https://github.com/nickjj/docker-node-example - https://github.com/nickjj/docker-phoenix-exam…
I maintain similar Django and Flask + compose stacks on behalf of the startup studio I work for so it’s fun to compare notes.
For our Django stack, for instance, we have also settled on Postgres, on celery+redis, and on whitenoise. black/flake8/isort also seem universally agreeable. We also throw in pyright and generally make extensive use of type hints.
For the front-end, we’re currently Create React App with TypeScript and Tailwind. I’d love for us to move away from CRA, so your use of esbuild is helpful to see. (I’d personally be happy using HTMX or Turbo/Stimulus but for the moment a JSON API backend with a React SPA front-end seems more comfortable for more of the CTOs who hop on board.)
We also supply some minimally opinionated glue at the API layer. On the back end we have a base View that provides a few helper methods for transmuting invalid Form instances to nice JSON replies that the TypeScript API invocation code works with gracefully. (We used to push DRF but have lots of feedback from older startups than ran with it and had regrets down the road.)
Earlier quoted context omitted.
What do you mean by "can't really use docker over SSH"? I'm not sure what that means, or how it's related to bind mounts.
I mean using a remote Docker context over SSH, where I run `docker` commands on my laptop, but it runs the containers on a remote Docker server. My laptop does not run the docker daemon, so its just a client. If you tell me to run docker run -v ${HOME}/stuff:/stuff alpine It will mount /home/stuff on the server , not my own home directory on my laptop. I would have to run another process that rsync's my local /home/s…
Or just go with k8s if you need a more complex setup.
Earlier quoted context omitted.
What do you mean by "can't really use docker over SSH"? I'm not sure what that means, or how it's related to bind mounts.
I mean using a remote Docker context over SSH, where I run `docker` commands on my laptop, but it runs the containers on a remote Docker server. My laptop does not run the docker daemon, so its just a client. If you tell me to run docker run -v ${HOME}/stuff:/stuff alpine It will mount /home/stuff on the server , not my own home directory on my laptop. I would have to run another process that rsync's my local /home/s…
Though, I'm still confused by your example of having to rsync /home/stuff to the server. If you use a named Docker volume, is the remote Docker container somehow using a volume you have located on your laptop? Wouldn't you still have to transfer the volume from laptop to server?
Earlier quoted context omitted.
I mean using a remote Docker context over SSH, where I run `docker` commands on my laptop, but it runs the containers on a remote Docker server. My laptop does not run the docker daemon, so its just a client. If you tell me to run docker run -v ${HOME}/stuff:/stuff alpine It will mount /home/stuff on the server , not my own home directory on my laptop. I would have to run another process that rsync's my local /home/s…
Thanks for the reply. I didn't know that was a thing. Though, I'm still confused by your example of having to rsync /home/stuff to the server. If you use a named Docker volume, is the remote Docker container somehow using a volume you have located on your laptop? Wouldn't you still have to transfer the volume from laptop to server?
In my system all of the files get written to the volume from only three places:
* From the docker image through VOLUME (fresh volumes copy the data from the image on start)
* From a template container that writes config files.
* From the container itself, writing files as it runs.
When I run `docker build` on my laptop, this does copy files to the server (Docker designed build this way, and you have to set .dockerignore file to ignore files you dont want copied).
Earlier quoted context omitted.
I mean using a remote Docker context over SSH, where I run `docker` commands on my laptop, but it runs the containers on a remote Docker server. My laptop does not run the docker daemon, so its just a client. If you tell me to run docker run -v ${HOME}/stuff:/stuff alpine It will mount /home/stuff on the server , not my own home directory on my laptop. I would have to run another process that rsync's my local /home/s…
Just run docker compose on the remote machine (and copy the compose file with scp). I don’t see a lot of benefits if you run docker compose on another machine than the docker daemon. You can even automate it with ansible, terraform, or similar, if you like it neat. Or just go with k8s if you need a more complex setup.
Also, its really nice to be able to use `docker context use SERVER_NAME` so I can switch contexts (servers) very easily.
Security note: specifying no version, or a version tag (and not an @-hash) in the docker image name allows DockerHub or the image publisher to replace the code underneath you on container restarts (ie RCE), as they are not cryptographically assured.
Sure, the image is changing now only at intentional times (as opposed to just any restart), but you're still not getting an assurance that a "trusted" upstream isn't going to RCE you. Security updates & patches come out with such frequency that the number of windows of opportunity are still plentiful.
Better advice would be to use tags, but to vendor the images somewhere and point at the vendored copies. You still get the "doesn't change on random restart", you have an idea of what version you're on that the hash doesn't tell you, you don't have to deal with Docker hashes being the weird AF things they are (e.g., you side-step the confusion that library/foo@sha256:XXXXX == vendored/foo@sha256:YYYYY), and you're more respectful of upstream's bandwidth and you're not dependent on their reliability concerns.
(And frankly, given how poorly most of the industry handles security updates, I'd argue that sitting on a very loose tag might be more secure overall, because then security patches might be happening at random times, as opposed to not at all. The trade-off of the RCE is worth it, and there are ways for upstreams to mitigate the risk there, centrally. Most companies struggle with just vendoring, and few get to actually keeping that up-to-date, IME due to a lack of willingness to apply the necessary resources to the problem.)
Security note: specifying no version, or a version tag (and not an @-hash) in the docker image name allows DockerHub or the image publisher to replace the code underneath you on container restarts (ie RCE), as they are not cryptographically assured.
Using @-hashes doesn't assure you of not getting pwned the same way here. How are you getting the @-hash, if not just looking at what the tag points to? Sure, the image is changing now only at intentional times (as opposed to just any restart), but you're still not getting an assurance that a "trusted" upstream isn't going to RCE you. Security updates & patches come out with such frequency that the number of windows…
It does, changes to the image could be pushed to "latest" or a specific tag, but the hash cannot change, once you've established that a specific hash is secure, it'll remain secure (or rather, as secure as you first established it as).
Security note: specifying no version, or a version tag (and not an @-hash) in the docker image name allows DockerHub or the image publisher to replace the code underneath you on container restarts (ie RCE), as they are not cryptographically assured.
...and you'd have to do that for every single security update for every single service that you run. If you need that level of security that might be appropriate, but most users need security patches more than they need to be concerned with a novel attack that requires DockerHub to intend to RCE them.
Harmful code pushed into large software repositories masquerade as something else is not novel and is starting to happen more and more.