Running as a Docker container

[mion00]

Hi and thanks for this add-on! I am beginning to explore the world of VoIP (to integrate HA with a SIP-enabled doorbell), and came across this project while searching for a Dockerized solution for running Asterisk. My setup however is based on Home Assistant Container, so no supervisor is present.

I have seen in the startup scripts that the add-on makes use of some functions that are only available for add-ons (bashio::config for instance calls the supervisor API, or the reference to the SUPERVISOR token).
I think that with minimal tweaking it could be possible to adapt these for a non-supervised install, for instance by mounting a json file with the configuration options, and by allowing to set the Home Assistant URL and secrets via env variables.
Running this outside of the add-on store may be also useful for local development, since that way testing code changes is as simple as starting and stopping a single Docker container, without needing a running instance of HA to install the add-on within.

While trying to run the add-on locally, I only came across these roadblocks for now. Are there any specific assumptions that this add-on makes that would require for certain the presence of the supervisor?
If the prospect of running this add-on standalone may be of interest for this project, I am happy to step in and contribute some code.

[felipecrs]

I don't forecast any other major roadblocks ahead. Also, I would suggest you to skip certain initialization scripts when not running as add-on, like for example the "auto add extensions", to make it simpler for you.

So, I think this is a great suggestion and I would be happy to review your changes once you make it. You have my go ahead.

@TECH7Fox any comments?

[TECH7Fox]

Sounds great. Let me know how it goes! 🙂

[mion00]

I am making some progress and I am able to start the container locally. Now I have the inverse problem: I would like to build the add-on locally to test if these changes have broken anything. 😏
I see you make use of the variable TARGETARCH https://github.com/TECH7Fox/asterisk-hass-addons/blob/main/asterisk/Dockerfile#L127, which I assume is populated by Buildkit.
However how do you build this as a local add-on? I copied the repo in the /addons/local folder of a test VM I am using, but the build invoked from the supervisor does not seem to use Buildkit under the hood.. 🤔

Step 21/58 : RUN if [[ "${TARGETARCH}" == "amd64" || "${TARGETARCH}" == "i386" ]]; then         curl -fsSL "https://github.com/tommyjlong/app_rtsp_sip/archive/${APP_RTSP_SIP_VERSION}.tar.gz" |         tar --strip-components 1 -xz;         patch -p1 < disable_auth.patch;         patch -p1 < remove_sudo.patch;         cp -f app_rtsp_sip.c /usr/src/asterisk/apps;         cp -f rtsp_sip_links.sh /usr/src/asterisk;         cd /usr/src/asterisk;         ./rtsp_sip_links.sh;     fi
 ---> Running in 80229c047273
/bin/bash: line 1: TARGETARCH: unbound variable

Am I missing something obvious?

[felipecrs]

You can't build this add-on using Supervisor. You have to have it built before and then Supervisor would only pull it.

[mion00]

I imagined something like that would be necessary.. 🤔
Just FYI we should update the dev docs, since I assume they still refer to a previous version of the add-on that could still be built like that.

[TECH7Fox]

You can't build this add-on using Supervisor.

I thought you could right? If you remove image from config.yaml of course.

[mion00]

You can't build this add-on using Supervisor.

You can right? If you remove image from config.yaml.

I have been trying to do it for hours without success, and I came to the conclusion that the build invoked from the supervisor is not the same as the one invoked manually by docker build (the latter uses Buildkit in the lastest release of Docker CLI)

[TECH7Fox]

Ah ok. Will change the docs then.