191–200 of 228 posts
But how does this work when talking to dev databases on my machine?
Getting a Docker compose dev env working is another can of worms. Maybe I should write about that next?
Earlier quoted context omitted.
> the extra memory usage on macOS It's worth noting that the Docker experience is very different across platforms. If you just run Docker on Linux, it's basically no different than just running any other binary on the machine. On macOS and Windows, you have the overhead of a VM and its RAM to contend with at minimum , but in many cases you also have to deal with sending files over the wire or worse, mounting filesyst…
Honestly, to an outsider Docker sure sounds like a world of pain.
If you freelance and work on different project, sure rvm is a great thing, but docker will contain it even better and you won't litter your work machine with stuff like mine is after a few years.
Earlier quoted context omitted.
Dockerized applications can still reach services on the localhost, but you may want to take a look at docker compose so you get your application and backing systems in one place. It makes your local development environment incredibly resilient.
Do you have an example how that would work? I unsuccessfully spent quite a while trying to get a docker container running rails to talk to a docker container running postgre. And I wanted to postgre container to persist to the host's disk so I could save state between runs. Maybe that wasn't the best way to do it though?
There are a lot of dockerfile / compose examples on github.
* https://github.com/docker/awesome-compose * https://github.com/jessfraz/dockerfiles
I used to think I hated Docker, but I think what I actually hate is using Docker locally (building/rebuilding/cache-busting images, spinning containers up and down, the extra memory usage on macOS, etc etc). I don't need all that for development, I just want to run my dang code But I've been really enjoying it as a way of just telling a PaaS "hey here's the compiler/runtime my code needs to run", and then mostly not…
Docker can be a pain sometimes (especially docker for mac!), but in moderately complex apps, it's so nice to be able to just fire up 6 services (even some smaller apps have redis, memcached, pg/mysql, etc) and have a running dev environment. If someone updates nodejs, just pull in the latest dockerfile. Someone updates to a new postgres version? Same thing. It's so much better than managing native dependencies.
I used to think I hated Docker, but I think what I actually hate is using Docker locally (building/rebuilding/cache-busting images, spinning containers up and down, the extra memory usage on macOS, etc etc). I don't need all that for development, I just want to run my dang code But I've been really enjoying it as a way of just telling a PaaS "hey here's the compiler/runtime my code needs to run", and then mostly not…
I don't use Docker locally except for building/testing production containers. I also found them not helpful for development. That said, I recently discovered that VS Code has a feature called "Dev Containers"[0] that ostensibly makes it easy to develop inside the same Docker container you'll be deploying. I haven't had a chance to check it out, but it seems very cool. [0] https://code.visualstudio.com/docs/devcontain…
web:
image: rubylang/ruby:3.0.1-focal
volumes:
- .:/myappEarlier quoted context omitted.
Yeah the fly.io stuff is great, beautiful artwork too, top class job. Re: security updates. It's not handled. There are companies that will scan your infrastructure to figure out what's in your containers and find out of date OS base images. One thing I'm currently experimenting with is a product for people who would like an experience slightly closer to traditional Linux. The gist is, e.g. include "#!gradle -q print…
> It's not handled. So... what do actual real people do in practice? I am very confused what people are actually doing here. LOTS of people seem to have moved to this kind of docker-based deploy for PaaS. They can't all just be... ignoring security patches? I am very confused that nobody else seems to think the "handle patches story" is a big barrier to moving from heroku-style to docker-style... that everyone else j…
They can and they are, IME. I've seen images that literally run some version of Alpine Linux from 3 years ago.
Earlier quoted context omitted.
I don't do backend work professionally so my opinion probably isn't worth much, but the way Docker is so tightly tied to Linux makes me hesitant to use it for personal projects. Linux is great and all but I really don't like the idea of so explicitly marrying my backend to any particular platform unless I really have to. I think in the long run we'd be better served figuring out ways to make platform irrelevant than…
It's, more or less, practically impossible to be OS agnostic for a backend with any sort of complexity. You can choose layers that try to abstract the OS layer away but sooner or later you're going to run into part of the abstraction that leaks. That plus the specialty nature of Windows/Mac hosting means your backend is gonna run on Linux. It made sense at one point to use Macs but these days pretty much everything i…
That’s quite the assumption. Graviton is very popular. I haven’t touched x64 stuff in a very long time. Perhaps such generalization is a bad idea.
Earlier quoted context omitted.
Not just you. Whenever you've covered your bases, Rails grows in complexity. Probably necessary complexity to keep up with modern world. Solved asset pipeline pain? Here's we packer. No, let's swap that out for jsbundle. Finally tamed the timing of releasing that db migration without downtime? Here's sidekiq, requiring you to synchronize restarts of several servers. Oh, wait, we now ship activejob. Managed to work ar…
> Finally tamed the timing of releasing that db migration without downtime? Here's sidekiq, requiring you to synchronize restarts of several servers To be fair, this was already an issue whenever you have more than one instance of anything. Whether it's an extra sidekiq or two web servers or anything else, you have a choice of: stop everything and migrate, or split the migration into prepare, update code, finalise mi…
But async workers have the tendency to be busy on long running processes, whereas a web server typically has connections that last at most seconds. Their different profile makes restarting just a tad harder.
Am I the only person who struggles to deploy Rails apps. It's a super productive framework to develop in, but deploying an actuals Rails apps - after nearly 20 years of existance, still seems way more difficult than it should be. Maybe it's just me.
With Ruby and Python, most instructions for getting something going is just a series of "install this or that", "modify this file over there", "you could do this or that", "call this, than that, and then that", etc. These instructions tend to be developer focused. Virtual environments are usually left as an exercise to the reader and failing to use those leaves you with a big mess on your filesystem. Just pretend your production server is a snowflake developer laptop and you'll be fine seems to be the gist of it. Except of course that doesn't quite work like that anymore in many places and you need to take some steps to prevent that.
I spend some time face palming myself through the Apache Air (python) documentation trying to figure out a sane way to get that on a production environment. As it turned out that involved jumping through quite a few hoops. My conclusion was that whoever wrote that, was not used to dealing with production environments.
So, good that they are tackling this in the rails community. Stuff like this should not be an afterthought. With docker, you don't really need any virtual environments anymore. And you can also use them for development. That actually simplifies getting started instructions for both developers and operations people. Just use this container for development and run this command to push your production ready image to your docker registry of choice. No venvs, no gazillions of dependencies to install, etc.
Earlier quoted context omitted.
You can build the first stage separately as a first step using `--target` and store the cache that way. No problem.
How would you do this in a generic, reusable way company-wide for any Dockerfile? Given that you don't know the targets beforehand, the names, or even the number of stages. It is of course possible to do for a single project with a bit of effort: build each stage with a remote OCI cache source, push the cash there after. But... that sucks. What you want is the `max` cache type in buildkit[1]. Except... not much suppo…
It worked wonders for us, on a cache hit the build time is reduced from 10 to 1,5 minutes.