runtime
runtime copied to clipboard
Run a short-lived one-off interactive container
I'm thinking about trying to replace the heroku run bundle exec rails console where it launches a new container of your image, runs the command given bundle exec rails console in this example, and when the command exits, clean up the container.
Is that supported?
When you run acorn exec you can optionally supply a "debug image". If you have a container that is running "FROM scratch" the debug image will be used to create an exec session that will use that image as the filesystem but then share the same pid and network namespaces as the target container. Also the volumes of the target container will be mounted in. That could work for your use case.
The API also support just running a one off container in the target namespace of the app, but it's not exposed through the CLI yet. But I think the first approach may work for you.
I think I'm actually thinking more the second approach. The example I gave is fairly key; rails console runs an interactive Ruby prompt with your application's classes all defined and connections to services available (sorry if I'm teaching you to suck eggs, but I don't know how much Ruby on Rails you know).
So I may do something like this:
bundle exec rails c
rails> user = User.find_by(email: "[email protected]")
rails> user.unlock!
Using a scratch image would be useful for debugging network connectivity or things of that nature, but most often Rails developers use this for looking at the state of the application (in the database, but via the models in the MVC structure so helper methods and relationships are defined) or to queue one off jobs to fix something.
This page on Heroku is the sort of thing I'm trying to achieve (and I'm literally wanting to move from Heroku to Kubernetes but using Acorn, so that may explain my background thinking for a lot of my requests) - https://devcenter.heroku.com/articles/one-off-dynos
Does this all help explain more what I'm trying to achieve?
Trying to triage this issue and need a point of clarification. Apologies if you already understood this, but "Using a scratch image would be useful..., but" threw me off a bit.
When darren says:
If you have a container that is running "FROM scratch" the debug image will be used to create an exec session
He isn't saying that the debug image is from scratch, he is giving the example that if your prod application image uses SCRATCH, that is going to be worthless for you to exec into, so you can use the "debug image" feature of exec to specify whatever image you want. This could be your rails-friendly image. It would things like pid and network namespace as your acutal running prod app.
Does that change your ask at all? Would acorn exec --container my-org/my-debug-image meet your needs?
I understand now. I think it would be nicer if this sort of Acornfile and commands were supported:
containers: {
worker: {
build: "."
image: "docker.io/something/myapp:latest"
}
web: {
build: "."
entrypoint: "web"
image: "docker.io/something/myapp:latest"
}
console: {
scale: 0
build: "."
entrypoint: "bundle exec rails c"
image: "docker.io/something/myapp:latest"
}
}
Then you could do:
acorn build # Builds the docker image and pushes it to docker.io
acorn push # Deploys to a cluster
acorn exec -c console # Runs a one-off container using the image/build specified for that container
That means if I have all my projects setup the same, I can just use acorn exec -c console in each one from my zsh history, without needing to look up the image URL every time I change projects.
What do you think?
That makes sense. To take it a half a step further, I think it would be nice UX for the "debug" container to be potentially baked into the acorn image by the acorn author so that users don't need to guess at what the right image would be.
I am going to say that this is related to these issues:
- https://github.com/acorn-io/acorn/issues/37
- https://github.com/acorn-io/acorn/issues/45
They all kind of circle the same area of being able to perform one-off actions against an app, whether that be a pre-dfined operation like "backup my database" or ad-hoc one like "connect to the app using this specific defined container"
Short-term solution will have to be the existing exec functionality, but as we look into jobs and operations, I think we should keep this usecase in mind.