Today I want to make the application portable to the raspberry. To achieve so, I'll have to containerise it (either that, or I'll run on the bare OS; in any case, there are some things to handle, like environment variables, etc.).

It is installed on lardafada, and now I install it on the raspberry. To ensure everything works well, I'll get a simple container running. Oh, and I almost forgot: I'm using Podman instead of Docker, just so I could get hands-on with this tool. It's not really a big deal: I don't think I did anything different, except for maybe a detail you'll see below.

Docker on the Raspberry is trickier than usual because of its ARM architecture — and mine is the model 3 no less, which still runs on 32-bit. Not all images are compatible with this. Alas, it just so happens when testing with a random Fedora image:

Trying to pull registry.fedoraproject.org/fedora:latest...
  no image found in image index for architecture arm, variant "v7", OS linux
Error: Error choosing an image from manifest list docker://registry.fedoraproject.org/fedora:latest: no image found in image index for architecture arm, variant "v7", OS linux

...but there is no reason to stick to Fedora; I'm just testing, after all. Debian it is.

pigre@pigrelair ➤ podman run --cgroup-manager=cgroupfs debian echo "hello, alex"                                                        
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs    
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available 
WARN[0000] For using systemd, you may need to login using an user session 
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root) 
WARN[0000] Falling back to --cgroup-manager=cgroupfs

Debian runs, although I had to additionally modify my /etc/containers/containers.conf file to use cgroupfs (and I'm not sure this would have happened with Docker). All done!

While the images are being pulled and containers built in the raspberry — it really does take very long — I'll some work towards making the MVP production appropriate.

It can be slightly overwhelming to think of how much one must do to properly deploy such an application; luckily, there's some very handy Django documentation to go through, and a command to boot.

apinto@lardafada tutogarden/tutogarden ➤ python manage.py check --deploy  

(for brevity sake, I will not disclose the result of the aforementioned command; it is long!)

Factoring settings.py into different files

To make a more clear distinction between development and production, I'll factor the default settings.py file in three: base.py, development.py and production.py, and set my Django project to choose accordingly.

tutogarden
├── asgi.py
├── __init__.py
├── settings
│   ├── __init__.py
│   ├── __pycache__
│   └── settings.py
├── urls.py
└── wsgi.py

By creating a folder and moving settings.py to its inside, python manage.py runserver does not run out of the box anymore. Adjust the command:

apinto@lardafada tutogarden/tutogarden ➤ python manage.py runserver --settings=tutogarden.settings.settings

which should run as expected. But this is not the final product: refactor whatever depends on running locally or in production; for example,

# settings/development.py
from .settings import *

ALLOWED_HOSTS = []
DEBUG = True

# settings/production.py
from .settings import *
ALLOWED_HOSTS = ["sbsbsb.sbs"]
DEBUG = False

Nothing very fancy here. But with the Dockerfile also in place, I can get the server running both locally and on the raspberry, which is nice — but that is not all. There were some hard-coded constants that must now be failing the tests.

apinto@lardafada tutogarden/tutogarden ➤ python manage.py test --settings=tutogarden.settings.production                      git:master
Found 7 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.......
----------------------------------------------------------------------
Ran 7 tests in 0.460s

OK
Destroying test database for alias 'default'...

Most likely I am not thoroughly testing my views.