cgwire / kitsu-docker

Dockerfile used to build the trial image of Kitsu

Kitsu Docker

Docker container for Kitsu.

If you like the project, please add a star to the Kitsu repository.

It is not recommended to use this image in production. It is intended for Kitsu testing.

For this purpose, to simplify email testing, we include an email catch-all application to intercept all emails sent by Kitsu. These can be viewed in an included webmail.

Usage

$ docker build -t cgwire/cgwire . # or sudo docker pull cgwire/cgwire
$ docker run --init -ti --rm -p 80:80 -p 1080:1080 --name cgwire cgwire/cgwire

In order to enable data persistence, use a named volume for the database and thumbnails:

$ docker run --init -ti --rm -p 80:80 -p 1080:1080 --name cgwire -v zou-storage:/var/lib/postgresql -v zou-storage:/opt/zou/previews cgwire/cgwire

To run the image as a daemon, add the -d flag:

$ docker run --init -d --rm -p 80:80 -p 1080:1080 --name cgwire cgwire/cgwire

Kitsu credentials:

• login: [email protected]
• password: mysecretpassword

URL:

Kitsu: http://127.0.0.1:80/

Internal webmail: http://127.0.0.1:1080/

Update

After updating the image, you have to update the database schema. For that run:

$ docker exec -ti cgwire sh -c "/opt/zou/env/bin/zou upgrade-db"

Docker Compose

Thanks to our community, for Docker Compose, an implementation by Mathieu Bouzard is available

About authors

This Dockerfile is written by CGWire, a company based in France. We help animation and VFX studios to collaborate better through efficient tooling.

More than 100 studios around the world use Kitsu for their projects.

Visit cg-wire.com for more information.

kitsu-docker's Issues

is this a production ready?

Hi,

because I'm using window!! so I think docker cgwire is the best way for me to start.
the only question is can we use this for production?

Thanks
Desmond

default credentials shown in readme are not working?

I just installed docker version on my linux desktop via cockpit ui. it worked perfectly (installed). Upon entering localhost:port i see its login screen but its not taking [email protected] and mysecretpassword (failing)
just wanted to know defaults or am i doing something wrong.

if its in-correct place to discuss, kindly close thing, thanks,haseeb

Wrong VOLUME

Wrong VOLUME
https://github.com/cgwire/cgwire/blob/master/Dockerfile#L77
'VOLUME ["/var/lib/postgresql", "/opt/zou/zou/previews"]'
actually in /opt/zou/zou/previews is empty.
It should be like this: 'VOLUME ["/var/lib/postgresql", "/opt/zou/previews"]'

when transferring data from VOLUME to another container, all previews were lost

Can't login using default credentials

Hello,
I tried to deploy your docker image on a local machine (macOS). It's throwing "Login failed" error when I'm trying to log into Kitsu using default credentials.
Chrome console outputs "Method Not Allowed The method is not allowed for the requested URL." message on /auth/login API path (HTTP 400 error is returned).

Docker compose - sys.stderr.write(f"ERROR: {exc}") : invalid syntax

Hi,

Steps to reproduce

I did the following steps on a CentOS Linux 8 x86_64 :

$ git clone https://github.com/cgwire/cgwire
$ cd cgwire/compose
$ docker-compose up -d

Issue

and I have the following error at step 17/34 :

Step 17/34 : RUN python3 -m venv /opt/zou/env &&     /opt/zou/env/bin/pip install --upgrade pip setuptools wheel &&     /opt/zou/env/bin/pip install zou==${ZOU_VERSION} &&     rm -rf /root/.cache/pip/
 ---> Running in ea16e8bf127b
Collecting pip
  Downloading https://files.pythonhosted.org/packages/cd/82/04e9aaf603fdbaecb4323b9e723f13c92c245f6ab2902195c53987848c78/pip-21.1.2-py3-none-any.whl (1.5MB)
Collecting setuptools
  Downloading https://files.pythonhosted.org/packages/4e/78/56aa1b5f4d8ac548755ae767d84f0be54fdd9d404197a3d9e4659d272348/setuptools-57.0.0-py3-none-any.whl (821kB)
Collecting wheel
  Downloading https://files.pythonhosted.org/packages/65/63/39d04c74222770ed1589c0eaba06c05891801219272420b40311cd60c880/wheel-0.36.2-py2.py3-none-any.whl
Installing collected packages: pip, setuptools, wheel
  Found existing installation: pip 8.1.1
    Uninstalling pip-8.1.1:
      Successfully uninstalled pip-8.1.1
  Found existing installation: setuptools 20.7.0
    Uninstalling setuptools-20.7.0:
      Successfully uninstalled setuptools-20.7.0
Successfully installed pip-21.1.2 setuptools-57.0.0 wheel-0.36.2
Traceback (most recent call last):
  File "/opt/zou/env/bin/pip", line 7, in <module>
    from pip._internal.cli.main import main
  File "/opt/zou/env/lib/python3.5/site-packages/pip/_internal/cli/main.py", line 58
    sys.stderr.write(f"ERROR: {exc}")
                                   ^
SyntaxError: invalid syntax
The command '/bin/sh -c python3 -m venv /opt/zou/env &&     /opt/zou/env/bin/pip install --upgrade pip setuptools wheel &&     /opt/zou/env/bin/pip install zou==${ZOU_VERSION} &&     rm -rf /root/.cache/pip/' returned a non-zero code: 1
ERROR: Service 'cgwire' failed to build : Build failed 

Seems related to the fact that pip dropped support for python 2 and 3.5 (in this case) : https://stackoverflow.com/questions/66212924/pip-sys-stderr-writeferror-exc-with-python-3-5

I don't really know how to solve that : the ubuntu 16.04 base image install python3.5 with apt? It's also mentionned that python2 is needed for supervisord in the Dockerfile (I also saw the usage of tini so what's the link between the two?)

Thanks again for making this open source!

Versions :

• cgwire : commit d2a30e3
• OS : CentOS Linux 8 x86_64
• Docker : Docker version 20.10.6, build 370c289
• docker-compose : docker-compose version 1.29.2, build 5becea4c

Init db and data when building the docker image

Hi
When i build the docker image, the database initialization does not complete. I guess it occurs when the zou script (init_db,is launched.
An exception is raised :

Traceback (most recent call last):
  File "/opt/zou/env/bin/zou", line 11, in <module>
    load_entry_point('zou==0.3.9', 'console_scripts', 'zou')()
  File "/opt/zou/env/lib/python3.5/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/opt/zou/env/lib/python3.5/site-packages/click/core.py", line 676, in main
    _verify_python3_env()
  File "/opt/zou/env/lib/python3.5/site-packages/click/_unicodefun.py", line 118, in _verify_python3_env
    'for mitigation steps.' + extra)
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment.  Consult http://click.pocoo.org/python3/for mitigation steps.

This system supports the C.UTF-8 locale which is recommended.
You might be able to resolve your issue by exporting the
following environment variables:

    export LC_ALL=C.UTF-8
    export LANG=C.UTF-8

Mail not working, how can I solve it?

EDIT by @nledez

So right now I'm using Kitsu from a docker container with good success, the only problem so far is that the mailing options don't work, so users cannot recover their password or receive notifications.

How can I solve this?

[ ..... cut part .... ]

Now... back on track... how can I solve the mail not working?

Thanks!

Not related to issue (moved by @nledez - may put this in a README pull request):
BTW I think it could be a good idea to mention this to other users, to have persistent data, but at the same time have everything in a container that is a folder in the host computer I'm using this command to create a named volume that points to a folder in the host system:

docker volume create --driver local -o o=bind -o type=none -o device="/Volumes/MacServer/Docker/kitsu" kitsu-storage

And the command I use to run the container is this one:

docker run --init -d -p 80:80 --name kitsu_bone -v kitsu-storage:/var/lib/postgresql -v kitsu-storage:/opt/zou/previews cgwire/cgwire

After that I use this to identify the container:

docker ps

And then I use this command to make the container auto-start always:

docker update --restart=always co1n2t345678

Being the big number the container ID I got with the previous command.

This way I'm able to access the actual data because it's inside an actual folder of my system.

Maybe you want to add this process to the possible process for other users, because I think it makes it easier to use the docker image as a production ready version :)

Req: Update docker version to current

When you have time, please, can you update docker to latest current kitsu versions?
thanks!

🚀 🎸 🍰

Postgresql failed on start

Hello,

I tried several times to install the docker container (PopOS 20.04 LTS), kitsu gui worked as expected but I cant login with the mail/password given.

After some research, I discovered that the DB wasn't working.

You can find here the Docker's log:

admin@pop-os:~/docker-cgwire/cgwire$ sudo docker run -ti --rm -p 80:80 --name cgwire -v zou-storage:/var/lib/postgresql -v zou-storage:/opt/zou/previews cgwire/cgwire
Running Zou...
2020-07-20 15:46:25,259 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
2020-07-20 15:46:25,262 INFO RPC interface 'supervisor' initialized
2020-07-20 15:46:25,262 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2020-07-20 15:46:25,263 INFO supervisord started with pid 10
2020-07-20 15:46:26,264 INFO spawned: 'gunicorn' with pid 13
2020-07-20 15:46:26,265 INFO spawned: 'gunicorn-events' with pid 14
2020-07-20 15:46:26,268 INFO spawned: 'redis' with pid 15
2020-07-20 15:46:26,269 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2020-07-20 15:46:26,270 INFO spawned: 'nginx' with pid 16
2020-07-20 15:46:27,288 INFO success: gunicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-07-20 15:46:27,288 INFO success: gunicorn-events entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-07-20 15:46:27,288 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-07-20 15:46:27,289 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2020-07-20 15:46:27,289 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-07-20 15:46:29,321 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2020-07-20 15:46:32,335 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2020-07-20 15:46:32,335 INFO gave up: postgresql entered FATAL state, too many start retries too quickly
^C2020-07-20 15:52:50,200 WARN received SIGINT indicating exit request
2020-07-20 15:52:50,200 INFO waiting for redis, gunicorn, gunicorn-events, nginx to die
2020-07-20 15:52:50,203 INFO stopped: nginx (exit status 0)
^C2020-07-20 15:52:50,888 WARN received SIGINT indicating exit request
2020-07-20 15:52:51,119 INFO stopped: redis (exit status 0)
2020-07-20 15:52:52,351 INFO stopped: gunicorn (exit status 0)
2020-07-20 15:52:52,353 INFO stopped: gunicorn-events (exit status 0)

Thank you

postgresql entered FATAL state, too many start retries too quickly

Docker version 25.0.3, build 4debf41
I found that I cannot login through Kitsu's default username and password, so I checked the console and got those error:

root@MyServer:~# docker run --init -ti --rm -p 80:80 -p 1080:1080 --name cgwire cgwire/cgwire
[WARN tini (7)] Tini is not running as PID 1 and isn't registered as a child subreaper.
Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
Running Zou...
2024-04-05 03:42:19,035 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
2024-04-05 03:42:19,039 INFO RPC interface 'supervisor' initialized
2024-04-05 03:42:19,039 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-04-05 03:42:19,039 INFO supervisord started with pid 12
2024-04-05 03:42:20,041 INFO spawned: 'gunicorn' with pid 15
2024-04-05 03:42:20,042 INFO spawned: 'gunicorn-events' with pid 16
2024-04-05 03:42:20,059 INFO spawned: 'redis' with pid 17
2024-04-05 03:42:20,060 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:20,063 INFO spawned: 'nginx' with pid 18
2024-04-05 03:42:21,082 INFO success: gunicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,082 INFO success: gunicorn-events entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,082 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:21,083 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:21,084 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-04-05 03:42:23,086 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:26,087 INFO spawnerr: unknown error making dispatchers for 'postgresql': EACCES
2024-04-05 03:42:26,087 INFO gave up: postgresql entered FATAL state, too many start retries too quickly

Native ARM64 Docker Image

Context
Studio name: Undisclosed
Kitsu version: Latest
Production type: VFX

Describe the bug
There's no arm64 build of Kitsu on DockerHub, would be great if part of the build system included building for arm64 so I don't need to build manually on every release.
ARM machines are getting increasingly performant and I'm able to run an 80-core 512GB VPC in Oracle Cloud for a 1/3 to 1/4 cost as an AMD/Intel (respectively) counterpart.
https://www.oracle.com/ca-en/cloud/compute/arm/

Screenshots

custom nginx container doesn't work well with kitsu

Here's my custom nginx server running in another Docker container:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name localhost 127.0.0.1;

        error_page 404 = @foobar;

        location @foobar {
            return 301 /; # 301 (redirect) if not found
        }

        # Declare proxies:
        location /api/ {
            proxy_pass http://<host-url>:5000/api/;
        }
        
        location /kitsu/ {
            sub_filter 'src=/css/' 'src=/kitsu/css/';
            sub_filter 'src=/js/' 'src=/kitsu/js/';
            sub_filter_once off;
            proxy_pass http://<host-url>:5000/;
        }

        # Use Access-Control-Allow-Origin header to allow pre-flight request checks
        location ~* \.(eot|otf|ttf|woff|woff2)$ {
            add_header Access-Control-Allow-Origin *;
        }
    }
}

All the Kitsu css/js files somehow ended up in /css/ and /js/ directories instead of /kitsu/css/ and /kitsu/js/ directories, which causes 404 whenever I connect to Kitsu.

Versioning

Hi @frankrousseau,

Would it be possible to add versions to the Docker images? At the moment, there exists only :latest which makes it tricky to guarantee a particular state for anything depending on this image.

Preferably, there would exist something akin to:

$ docker run cgwire/cgwire:0.6

Such that I know what to expect when pulling this image, that it cannot change its behavior without my knowledge and that when I upgrade it is known and explicit.

Docker build errors

Hi !
I've noticed errors during docker build since 0.4.6 or 0.4.7.
Errors occured when executing zou (zou init_db zou init_data and zou create_admin)
Here's the log :

Traceback (most recent call last):
  File "/opt/zou/env/bin/zou", line 11, in <module>
    load_entry_point('zou==0.4.7', 'console_scripts', 'zou')()
  File "/opt/zou/env/lib/python3.5/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/opt/zou/env/lib/python3.5/site-packages/click/core.py", line 676, in main
    _verify_python3_env()
  File "/opt/zou/env/lib/python3.5/site-packages/click/_unicodefun.py", line 118, in _verify_python3_env
    'for mitigation steps.' + extra)
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment.  Consult http://click.pocoo.org/python3/for mitigation steps.

This system supports the C.UTF-8 locale which is recommended.
You might be able to resolve your issue by exporting the
following environment variables:

    export LC_ALL=C.UTF-8
    export LANG=C.UTF-8