Run application on boot

I’m about done with developing my application with VS code and now it’s time to make the program run when I turn on the device. I’m not quite sure how to do that.
Questions:
I’m assuming a docker-compose file is how to get this done, In VS code I have setup certain configurations, like volumes, ports, and devices. Do I need to put those in mu docker compose if my image was already made with them from VS code?

I looked at the Using multiple containers, but it didn’t tell me if when I run the image if my application will start automatically or I have to add a section to the docker compose to make that work.

When I run my image from a docker compose the log shows

/bin/sh: 1: exec: /Lavit/Lavit: not found

Meaning my application isn’t there ??? any thoughts.

Greetings @jeffbelz,

There’s many parts here to your question so let’s break it up so that we can easier discuss.

In VS code I have setup certain configurations, like volumes, ports, and devices. Do I need to put those in mu docker compose if my image was already made with them from VS code?

In short yes. These configurations in VS Code become run-time arguments on how a container should be ran. Without them it’s unlikely your container will work as expected. Our extension should have an easy way to create such a docker-compose file however. The Torizon: export docker-compose file command provided by our extension should produce a properly formatted docker-compose file with all the configuration for your project.

I looked at the Using multiple containers, but it didn’t tell me if when I run the image if my application will start automatically or I have to add a section to the docker compose to make that work.

A docker-compose file is just a file that describes the run-time arguments for your container. In order for this to be automatically started you need another service that does this on boot. Fortunately we have such a service in TorizonCore, basically if your docker-compose is in the correct spot in the device filesystem it will be ran on boot.

The best way to do this would be the following article here: Pre-provisioning Docker Containers onto a TorizonCore image

This article will guide you in how to create a TorizonCore image that has your container images and docker-compose file set up for running on boot.

When I run my image from a docker compose the log shows
/bin/sh: 1: exec: /Lavit/Lavit: not found
Meaning my application isn’t there ??? any thoughts.

Are you running the debug or the release version of your container? The debug version does not have the application binary built in to the container, while the release version does.

Best Regards,
Jeremias

I want to follow up on this one. I managed to get the docker-compose file all set and I can run it from the command line and all my containers start. I need to do this when the SOM boots. You mentioned " basically if your docker-compose is in the correct spot in the device filesystem it will be ran on boot."

What is the directory location. I don’t want to pre-provision yet. I have a demo and after that I will still being doing development. So, i’d like to put my docker compose in that file location for the demo, then take it out, so I can do more dev work,

What is the directory location.

The location is /var/sota/storage/docker-compose/docker-compose.yml. Basically if this file exists the systemd service (docker-compose.service) will try to bring it up on boot. For your demo you can modify the service I mentioned if you need slightly different behavior. Or if you need to just disable it for a time.

When you are ready for pre-provisioning later, this is the location that TorizonCore Builder will place your compose file. So the behavior should be the same.

Best Regards,
Jeremias

I can’t cd into /var/sota permission denied. I used sudo cd /var/sota and that did not work either.

Ideas?

Never mind.

For any one wondering use sudo -i to get into a root shell. Then I chmod -R 777 /var.

I know, I know not really a great thing to do…but it makes things a lot
easier

You should be able to also just use sudo to write into /var/sota/storage/docker-compose/docker-compose.yml without having to cd into it at all.

Adding my docker compose to the the one in the folder did not work. I can see the containers started, but then stopped for some reason. When I run just my docker compose from the command line it runs fine. I even just tried running my containers, and deleted the one in the compose file. Same deal…the containers start, but then stop. I tried to run the docker compose in the /var…/docker-compose folder from the terminal, but that failed too. It gave me errors like bad config parameter. Its it a permission thing again? I’m out of ideas, but I do have autoboot this compose file some how. I was going to put it in a script file and put it n the profile.d folder, but thought that might brick my system.
docker-compose.all.yml = what I run at the command line
docker-compose.yml = the modified file in the /var…/docker-compose/ folder.

docker-compose.All.yml (2.6 KB)

docker-compose.yml (4.3 KB)

Took a different approach and wondering if this is a good way to do this. I have not had a chance to try this on my full system, but for my simple hello program it worked.

  1. Make your docker compose file (docker-compose.myTest.yml)

  2. make a .service file. (myhello.service)
    -----------Service file start-----------------
    [Unit]
    Description=Service for hello
    Requires=docker.service
    After=docker.service network.target

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/torizon
ExecStart=/usr/bin/docker-compose -f /home/torizon/docker-compose.myTest.yml up -d
ExecStop=/usr/bin/docker-compose -f /home/torizon/docker-compose.myTest.yml stop
StandardOutput=syslog

[Install]
WantedBy=multi-user.target
-----------Service file end-----------------

  1. Copy service file to service folder (sudo cp myhello.service /etc/systemd/system)
  2. reload (sudo systemctl daemon-reload)
  3. tell it to run at startup (sudo systemctl enable myhello)

Looking at your compose files. For docker-compose.yml, did you just append your compose file contents at the end of what was already there? Why not just replace the contents of /var/sota/storage/docker-compose/docker-compose.yml with your compose file completely?

If you look at the compose file in your /var/sota/storage/docker-compose/docker-compose.yml you have definitions for containers that aren’t even related to your application stack. Also you have issues like 2 weston services being defined.

Best Regards,
Jeremias

yeah, I tried just using the contents of my compose file and replacing it, but it did not work either

I think it was version of my docker-compose. If you notice the one I combined has no version and when I re-did it I think I put version “3.0” I just did my method with the crank demo containers and it gave me the same errors, " Invalid type in volume, it should be a string" this is because of the version you put in the compose file. I told it to use version “2.4” and I was able to get the crank demo to boot on power up. I’ll port this thought process to our machine. It may take a few days, but I’m fairly certain the docker-compose version slipped me up

Strange, I guess your compose file had something where the version of docker-compose matters. Well glad you were able to get that resolved.

Best Regards,
Jeremias