weaveworks / ignite

Ignite a Firecracker microVM
https://ignite.readthedocs.org
Apache License 2.0
3.49k stars 224 forks source link

Is there a way to run the OCI image entrypoint/cmd/app automatically? #874

Open subzero112233 opened 2 years ago

subzero112233 commented 2 years ago

I may be missing something, but the farthest I managed to get was having the VM boot properly, and then need to do ignite exec $COMMAND or SSH to it to run my application.

the command I use: ignite run my-image:latest --ssh --size 5GB --runtime docker --ports 8888:8888 --network-plugin docker-bridge

I am using the latest ignite-ubuntu image, which I added stuff to obviously.

darkowlzz commented 2 years ago

Hi, thanks for trying ignite. Unfortunately, there's no way to do that. You have to exec separately to run the command you want to run. OCI image is used for the rootfs of the VM. Unlike containers, run in this case is to run the machine. Individual processes have to be run separately. You should be able to run startup jobs if you configure it in the filesystem correctly, depending on the OS.

stealthybox commented 2 years ago

If you add a systemd unit file to the proper directory within the Docker container, it will start your service on boot. This is the case for most packages you install that run their own server (apache/nginx/mysql/postgres).

If you're running you're own app, you will write your unit file yourself.

subzero112233 commented 2 years ago

The. What’s the point in supporting docker if you cannot run their commands?

matti commented 2 years ago

The. What’s the point in supporting docker if you cannot run their commands?

this.

subzero112233 commented 2 years ago

It just doesn’t make sense to have to run the container “anonymously” and then execute the command externally. There is a huge potential in this project, but it it just too cumbersome to get up and running.

solarkraft commented 2 years ago

Why not add this as an option to a VM's configuration file?

Unfortunately, there's no way to do that.

Individual processes have to be run separately.

Is there a technical reason for that? Isn't it easily possible to read the exec-commands out of the OCI and run them?

Is it more like a design decision (out of scope)? If so, I'd be interested in the reasoning. It does seem like a pretty big hurdle for first time/casual users.

You should be able to run startup jobs if you configure it in the filesystem correctly, depending on the OS

This is a good hint, however it's something no standard container image does (since they work with those commands). Considering the tight integration with container images (I don't currently see an way to easily build on top, supplying something like a Dockerfile or file system overlay, e.g. to add said systemd unit), isn't good compatibility with them a goal of this project?

vistaarjuneja commented 1 year ago

This issue has been blocking us for a while. We've not been able to run ssh on a a docker image using a custom base image (which was created by exporting a VM image). Adding it in RUN does not work as it just starts ssh in the intermediate container, and CMD/Entrypoint are not supported by ignite. Open to hearing any ideas or workarounds to support something like this. Even an option to provide a startup script inside the VM (which is present in the image) after the VM starts up would resolve this.