Docker Community Forums

Share and learn in the Docker community.

How to run a service in an image

Hello,

We have a docker image and we run our build process in it. At some point in the build process we need to execute an application that needs a service to be running.

The image is based on Ubuntu 14.04.
The service needs to be started when we run in the image. The service needs root privilege to be started, but the build process is run with normal user privilege.

To be more precise, codemeter is the service I want to start. Codemeter is installed in the image but service is not running. And I need it to encrypt my application. To start the service, the command is

service codemeter start

The command I run to start the build process in the image is :

docker run --rm -it -u 1000 -v git rev-parse --show-toplevel:/home/developer/dev -w /home/developer/dev mono_build_x32:v1.7 bash -c

Can you help?

Based on what you are saying, your container requires 2 “services” running in the container.
That can be done by coding up a script which launches both the codemeter service and your build.
I recommend that you launch the codemeter service as a background process instead of an Upstart or Systemd service. Refer to the Docker documentation at this link for details -> https://docs.docker.com/config/containers/multi-service_container/

Yes I’ve already read it. Maybe I’ve missed something.
But the keypoint of my question is how can I start the service with root privilege and run my scripts with developper privilege.

See what I get.

developer@88509c9c35b9:~/dev$ service codemeter start

  • Starting CodeMeter Server  codemeter
    start-stop-daemon: unable to set gid to 1 (Operation not permitted) [fail]

But run as root would work.
Thank you!

What about something like this:

  1. Start the container with a docker container run command as root with the codemeter service configured to always run as the default service. Specify all of the docker container run options that your application build will need: volumes, etc.

  2. Run your build in that existing running container by issuing a docker container exec command as the “developer” user with the “command” or “script” that runs your build.

Start the container with a docker container run command as root with the codemeter service configured to always run as the default service.

How do I do that (see bold text above)?

How would you run the codemeter service if you just ran the binary?

I don’t understand what you mean. The command to run the service is :
service codemter start
But can you write me command to execute?

docker run --rm -it -u 0 -v git rev-parse --show-toplevel :/home/developer/dev -w /home/developer/dev mono_build_x32:v1.7 bash -c ‘service codemeter start’

Is that it?

Do you currently have codemeter running in a container?

No! We have a image with codemeter install in it (dpkg of the .deb file).
The service doesn’t start automatically when I call docker run. Then I want to start it manually, with root privilege.
The only way I know is to pass -u 0 to my docker run commmand.
But I want to run the build scrtips with -u UID (e.g. 1000).
That’s what I’m trying to do. If there’s a way to have the service running automatically when I start run the image while using -u UID it would be great. But I don’t know how to do it.

Our current build command is
docker run --rm -it -u 1000 -v git rev-parse --show-toplevel :/home/developer/dev -w /home/developer/dev mono_build_x32:v1.7 bash -c ‘python build.py’
-v and -w parameters are for information. The key point of our command is :
docker run --rm -it -u 1000 mono_build_x32:v1.7 bash -c ‘python build.py’

Okay.

Run this command on a Linux machine where the codemeter service is still running to display the codemeter process.

pgrep -a -l codemeter | head -n 1

That should show you how codemeter is started by the Linux Service component (which could be Upstart or Systemd).

Here’s an example showing the sshdservice process.

🐳  root@172.28.128.3:[~] $ pgrep -a -l sshd | head -n 1
747 /usr/sbin/sshd -D

So the sshd service is started by running /usr/sbin/sshd -D.

You need to determine how codemeter is started.
Then make a docker image for codemeter with a Dockerfile.
In the Dockerfile you will need to install codemeter.
Then the CMD statement in the Dockerfile will need to contain the command to run it.

Example for sshd

CMD ["/usr/sbin/sshd", "-D"]

Then when you run a container from the codemeter docker image the codemeter service will run.

Then make a docker image for codemeter with a Dockerfile.

Does it could be added to our current docker file? I mean, just modify our current image…
I’ll try it by the end of the day.

Yes, that’s the outcome of this.

I’m not familiar at all with codemeter. So I don’t know how it’s installed and if it is configured to run as an Upstart Linux Service or Systemd Linux service https://en.wikipedia.org/wiki/Systemd

You will need to do some investigating of codemeter on your Linux virtual machine.

sshd on Ubuntu is configured as a Systemd service.

$ cat /etc/systemd/system/sshd.service
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

I will get back to you. Thank you for this information.
I think I’ve found a way of having the service running. But I’m not sure it is a good way for codemeter.
I’m either in a discussion with their team. I’m sure I’ll find the better procedure. I’ll keep you in touch.

Thank you for your help. I’ve found a way to start the server by executing the core application (and not via service start), by using the pgrep command you told me.
The service is not started via the CMD command (docker file), but started when I run the build scripts.