Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SIP in docker container
#1
Hi all,
   I have just installed SIP into a container (via git), exposed the port 80 and started off the service by python3 sip.py from /SIP within the container.
  Everything worked out, service is reachable....
   However, I tried to enable the relay_16 plugin and got the following reported by sip on the console:
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:22] "HTTP/1.1 GET /plugins" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:22] "HTTP/1.1 GET /api/log" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:25] "HTTP/1.1 GET /browse-plugins" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:25] "HTTP/1.1 GET /api/log" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:34] "HTTP/1.1 GET /inst-plugins" - 303 See Other
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:34] "HTTP/1.1 GET /plugins" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:35] "HTTP/1.1 GET /api/log" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:44] "HTTP/1.1 GET /upd-plugins" - 303 See Other
Code:
System is restarting
Code:
zones changed
Code:
GIPO 11 switched to state 1
Code:
[0, 0, 0, 0, 0, 0, 0, 0]
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:44] "HTTP/1.1 GET /restart" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:44] "HTTP/1.1 GET /api/log" - 200 OK
Code:
Restarting...
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:45] "HTTP/1.1 GET /static/scripts/goHome.js" - 200
Code:
Failed to connect to bus: No such file or directory
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:45] "HTTP/1.1 GET /" - 200 OK
Code:
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:45] "HTTP/1.1 GET /api/log" - 200 OK


 The browser reported back in a (I guess browser provided window):

SIP could not restart
Please restart the programm from command line

This I did and the plugin is showing up...everything sees ok...
Somebody has an idea to overcome that restart-step? or can somebody maybe post a working Dockerfile and a docker run ....?

Many thanks for your support!

Kind regards,
     Michael
Reply
#2
when a new plugin is enabled a restart of SIP is required in order to load the plugin.

The message
"SIP could not restart
Please restart the programm from command line"
is raised when SIP is started from the command line and an automatic restart happens.

SIP is usually started at boot time using a systemd service as described in the documentation:
https://github.com/Dan-in-CA/sip/wiki/Installation

under
"The recommended method:
Starting sip.py from a script in /etc/systemd"

When this is enabled any automatic restart will proceed without user input.

I am not sure how this would work in a docker container.

Dan
<p><br></p>
Reply
#3
Hi Michael,

Restarting SIP within a container doesn't seem logical to me. Once SIP stops (or dies) the container should be killed.
Usually you should configure the entire application and its environment in the dockerfile. If you update a container from within the container your dockerfile will be out of date.
Ideally you should keep the specific settings etc. outside the container. In this case I would create a git repository with all specific commands and settings. In the dockerfile then just before starting SIP you can do a git clone and if necessary fire up some stuff to get prepared.

Hope this make a little sense,
--Gerard
Reply
#4
well, I searched and found, even reported in that forum, that steve bruggeman got obviously sip working in a container. By manageing volumes, any configurations would survive a container restart...such volumes export I need to give a trial...the issue I have is, that the container itself remains alive while sip inside failed at restart when ie. a configuration is changed, needed to be reloaded...I will adapt my docker run with the -v setting ...and lets see ...i'll keep you informed...

I am still of the opinion that even sip is a kind of service that fits into a containerized service landscape...altough it is that easy to be installed and capsulated...additionally, i am switching my underlying hardware from time to time...so it is just about taking images and containers with me.
Kind regards and thx for your feedback so far
Michael
Reply
#5
Hi again,
just tested the settings dockerfile/docker-compose that should have worked out for steve bruggemann's sip-docker setup...and it didn't made the trick...so, I guess, I try to get in touch with Steve to ask him whether he faced once the same issue I do now...still the same...access to portal works fine, bit everytime a sip restart is required (note: not the container!) this strange error message is displayed...
Looking at the logs from above:

Restarting...
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:45] "HTTP/1.1 GET /static/scripts/goHome.js" - 200
Failed to connect to bus: No such file or directory

..something wrong with absulte/relative pathes in SIP modules or outside?

Kr,
Michael
Reply
#6
(2020 Jun 13, 07:49 AM)mimer Wrote: Hi again,
  just tested the settings dockerfile/docker-compose that should have worked out for steve bruggemann's sip-docker setup...and it didn't made the trick...so, I guess, I try to get in touch with Steve to ask him whether he faced once the same issue I do now...still the same...access to portal works fine, bit everytime a sip restart is required (note: not the container!) this strange error message is displayed...
Looking at the logs from above:

Restarting...
::ffff:192.168.178.70:37038 - - [12/Jun/2020 09:53:45] "HTTP/1.1 GET /static/scripts/goHome.js" - 200
Failed to connect to bus: No such file or directory

..something wrong with absulte/relative pathes in SIP modules or outside?

Kr,
Michael


The old image "sbruggeman87/sip-docker" I tried a long time ago but isn't working. Also it is based on python2.

Just now I tried to create an SIP image from a Dockerfile and it works. For the data directory I used a mount point. So far so good. However when adding plugins either via a manual update or via the Dockerfile I think I'm missing something how plugins are handled in SIP. Copying files as described in the Manifest file isn't sufficient apparently.

However when I put the whole SIP installation on the mount point (almost) everything works fine. Adding and enabling plugins do work. So not ideal but it is working (kind of).

In all cases you should restart the container when SIP wants to restart itself. That is how it is and should be in a containerized world. If the (main) process is gone, the container should also be gone. If you have a cluster like kubernetes a new image will be fired up by the cluster.

For now I can't see advantages in using docker for SIP since it runs mostly on a Pi or other sbc. What are your arguments (apart from that is is a lot of fun to do) to want to containerize SIP? 

--Gerard
Reply
#7
well, SIP brings everything with itself, so indeed capsulation in a docker container looks like some overhead. But I would like to adhere to having dedicated services containerizied.
Do you use port 80 to access SIP?...i installed SIP on an other PI directly on the OS, even with enablement of systemd service. I switched to port xyz and the browser showed even there the message i already mentioned in prevoius thread...that looks very strange...is the 80 port somewhere hardcoded? 
If as you propose the container needs to be restarted after a change...how csn i get such a container start be retriggered...whwt is the trigger on which a container restart could be base upon?
Michael
Reply
#8
Hi there,
I got in running without facing the message again. Issue was propably related to my own sip.service file (not noted before that exists in SIP folder a template for that)...However issue running sip.py in a container is still there...obvouisly, the changes that causing the applicable scripts to restart sip cannot handle docker environment...my dockerfile maps the internally (by SIP) used port to an external one -p 9300:80....the SIP is, thus, reachable from the host by <ip-of-host>:9300...
I am guessing that's maybe an issue, but for sure I am not an export on this...

...BTW: installed the relay 16 plugin...activiation failed with message (see above) ...restart of container brought the plugin up...tried to limit the amount of relais...than I faced in internal server error...I am really kneen to get to known...how a restart is forced based on which parameters...
Reply
#9
tried to enable systemd/systemctl sip3.service ...service got enabled, but failed, died at the end...tried of with the systemd-replacement -> gdraheim/docker-systemctl-replacement
everything works fine, service is up..but everytime SIP forces due to an update a restart...the services dies... a simple start from CLI shows up the changes...but that's nt the use case to do that everytime...something is weired in docker <-> sip.py communication...no further ideas...
Reply
#10
Regarding port number, yes I do use SIP on port 80. In the options page (or config file) you can change it to another port.

Since SIP within docker is the (sort of) only process (pid=1) it is expected (desired) behavior to exit the container. There is nothing else to do anymore.
Usually the docker management framework like kubernetes will get notified and will/should fire-up the container again.
You could also configure autostart like "docker run -d --restart unless-stopped ....."

For debugging I assume you run or start the container with the interactive switch like "docker run -it .." or "docker start -i.....". That should point you in the right direction.... hopefully :-)

--Gerard
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)