Cannot start Plausible from a docker compose file on Azure

[guillaumemeyer]

Past Issues Searched

• I have searched open and closed issues to make sure that the bug has not yet been reported

Issue is a Bug Report

• This is a bug report and not a feature request, nor asking for self-hosted support

Describe the bug

When hosting the platform on Microsoft Azure App Services, the container provisioning process pulls all the images successfully from the Docker public registry, then stops with an error (probably from entrypoint.sh):

multi-container unit was not started successfully
...
2021-09-01T11:13:24.001Z INFO  - Container logs from xxx_plausible_0_e338f565 = 2021-09-01T11:12:47.044901638Z 10: line 1: syntax error: unterminated quoted string
2021-09-01T11:12:57.035222652Z 10: line 1: syntax error: unterminated quoted string
2021-09-01T11:13:06.853591019Z 10: line 1: syntax error: unterminated quoted string

Expected behavior

The provisioning should be able to start the container images

Screenshots

Here's the docker-compose.yml file used:

version: "3.3"
services:
  mail:
    image: bytemark/smtp
    restart: always
  plausible_events_db:
    image: yandex/clickhouse-server:21.3.2.5
    restart: always
    volumes:
      - event-data:/var/lib/clickhouse
  plausible:
    image: plausible/analytics:latest
    restart: always
    ports:
      - "80:8080"
    command: sh -c "sleep 10 && /entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh db init-admin && /entrypoint.sh run"
volumes:
  event-data:
    driver: local
  geoip:
    driver: local

As you can see this is a very streamlined version of the sample docker compose file, to accommodate with the Azure environment limitations of docker compose support.

Environment

- Hosting: Microsoft Azure
- Service: Azure App Services with Docker Compose

[guillaumemeyer]

Forgot to mention that the environment variables are passed through the application settings:

[guillaumemeyer]

OK, moved to a discussion... the issue clearly points to an error in entrypoint.sh, don't you consider this as an issue @metmarkosaric ?

[ukutaht]

We only create issues for detailed and specific problems that we intend to fix.

We've designed the software for Linux environments with full docker-compose support. If your platform doesn't fall in that category, I don't intend to debug and fix it, at least not at this time.

We're always open to contributions so you're welcome to send a PR.

[guillaumemeyer]

ok makes sense thanks. I'll try to move from Azure App Service to Azure Container Instance

[ukutaht]

Hope I didn't come off as rude in that message. I'm a single developer maintaining the whole thing so I have to be ruthless about setting priorities. Sorry we cannot support all the platforms at the moment!

[devhawkio]

@guillaumemeyer did you ever get this working? I am trying and receiving the same error.

[devhawkio]

I will admit I lost about a day to this issue. The unique aspects of shell commands exec and sh -c are a mystery to me. But the problem is that when deploying to the Azure App Service with docker compose, the compose yaml cannot have an sh -c with a complex string of multiple commands (ie. "sh -c x && y && z"). So I reworked the entrypoint.sh as follows:
`#!/bin/sh
set -e

sh -c "sleep 10 && /app/createdb.sh && /app/migrate.sh && /app/init-admin.sh && /app/bin/plausible start"`

This allows you to remove the entrypoint argument in docker compose and still run the same script. As well, my Dockerfile ends with:
`COPY .gitlab/build-scripts/docker-entrypoint.sh /entrypoint.sh

RUN chmod a+x /entrypoint.sh &&
adduser -h /app -u 1000 -s /bin/sh -D plausibleuser

COPY --from=buildcontainer /app/_build/prod/rel/plausible /app
RUN chown -R plausibleuser:plausibleuser /app
USER plausibleuser
#WORKDIR /app
ENV GEONAMES_SOURCE_FILE=/app/lib/plausible-0.0.1/priv/geonames.csv

EXPOSE 8000
ENTRYPOINT ["/bin/sh","-c","/entrypoint.sh"]`

Let me know if you would like to include this in the repo. My outsiders perspective is that the startup scripts are a bit convoluted and could be streamlined along with the Dockerfile user issue.

[ukutaht]

Thanks @devhawkio!

I'd like to preserve the current behaviour where the entrypoint does NOT automatically run migrations and apply ./init-admin. While this is useful for self-hosted docker-compose installations, we have different needs for our hosted platform.

My outsiders perspective is that the startup scripts are a bit convoluted and could be streamlined along with the Dockerfile user issue.

I definitely agree with that, and would happily merge any improvements.