> Everything after that removes the manifest files and any temporary files downloaded during this command. It's necessary to remove all these files in this command to keep the size of the Docker image to a minimum. Smaller Dockerfiles mean faster deployments. It isn't explicitly explained, but the reason why it must be in this command and not separated out is because each command in a dockerfile creates a new "layer"…
If you only care about the final image size, then `docker build --squash` squashes the layers for you as well.
Rails on Docker
11–20 of 228 posts
Re: Rails on Docker
#12This is really cool. Is the Rails server production ready? I was always under the impression you had to run it with Uvicorn or similar, although I haven't been following Rails development recently.
Re: Rails on Docker
#13I 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 need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
Re: Rails on Docker
#14> Everything after that removes the manifest files and any temporary files downloaded during this command. It's necessary to remove all these files in this command to keep the size of the Docker image to a minimum. Smaller Dockerfiles mean faster deployments. It isn't explicitly explained, but the reason why it must be in this command and not separated out is because each command in a dockerfile creates a new "layer"…
If you only care about the final image size, then `docker build --squash` squashes the layers for you as well.
Re: Rails on Docker
#15I 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 need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
And 50% of the time it actually works. The other 50% of the time, it doesn't, and I spend a week talking to other engineers and ops trying to figure out why.
Not a jab at Docker, btw.
Re: Rails on Docker
#16Earlier quoted context omitted.
> I don't need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
I certainly have. And there is often a Dockerfile or a docker-compose file. And the docs will say "just run docker-compose up, and you should be good to go." And 50% of the time it actually works. The other 50% of the time, it doesn't, and I spend a week talking to other engineers and ops trying to figure out why. Not a jab at Docker, btw.
Re: Rails on Docker
#17Earlier quoted context omitted.
> I don't need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
I certainly have. And there is often a Dockerfile or a docker-compose file. And the docs will say "just run docker-compose up, and you should be good to go." And 50% of the time it actually works. The other 50% of the time, it doesn't, and I spend a week talking to other engineers and ops trying to figure out why. Not a jab at Docker, btw.
Re: Rails on Docker
#18I 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 need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
IMO Docker for local dev is most beneficial for python where local installs are so all over the place.
Re: Rails on Docker
#19Earlier quoted context omitted.
If you only care about the final image size, then `docker build --squash` squashes the layers for you as well.
--squash is still experimental, I believe multi-stage images are the new best practice here.
FROM the_source_image as builder
RUN build.sh
FROM the_source_image
COPY --from=builder /app/artifacts /app/
CMD ....
i'm not sure if you can really call it the new best practice though, its been the default for ... a very long time at this point.Re: Rails on Docker
#20Earlier quoted context omitted.
> I don't need all that for development, I just want to run the dang code Have you ever worked somewhere where in order to run the code locally on your machine, it's a blend of "install RabbitMQ on your machine, connect to MS-SQL in dev, use a local Redis, connect to Cassandra in dev, run 1 service that this service routes through/calls to locally, but then that service will call to 2 services in dev", etc?
Docker compose for those services while the language itself runs natively has been the best solution to this problem for me in the past. Docker compose for redis, postgres, elastic, etc. IMO Docker for local dev is most beneficial for python where local installs are so all over the place.