switch to alpine image

[fyliu]

Fixes #177

What changes did you make?

• switched docker build to start from alpine base image
• added Roboto font
• modified erd.sh script to produce the same result as before without pydot
• removed some packages that used to be installed by apt

Why did you make the changes (we will use this info to test)?

• Switching to alpine is to save space, download time, and build time
• alpine doesn't come with fonts so I installed the Roboto font which is hard coded by the graph_models command
• The graph_models command using pydot doesn't produce the correct output anymore, so I split the operation into 2 commands in the erd.sh script and removed pydot as a dependency
• Other python package dependencies were removed here. I suspect they may have been generated by uv in an earlier PR (#268) where it detected my system python to be 3.12. This time I made sure to generate the requirements.txt using the python 3.10 in the docker image.
  • The strange thing is I noticed the extra additions at the time of that older PR and tried without success to generate one that didn't have them, and running against the python in the image was something I thought about. I even added a script to call it, which I'm sure I ran at the time. That's the script I ran this time.
• Some of the apt-installed packages are not needed by django or erd-generation.
  • postgres doesn't seem to be required according to several team members
  • I remember the older graphviz or pydot version required gcc, which is no longer the case
  • netcat was used in the database wait script, which we removed

Testing suggestions

• make sure it builds and the tests still pass

• run scripts/erd.sh and make sure it still generates app/erd.png, and running file app/erd.png from the host system shows a normal image and not something like 1px x 800000px

  ❯ file erd.png 
  erd.png: PNG image data, 4391 x 1396, 8-bit/color RGBA, non-interlaced

• check that django admin looks okay

[drakeredwind01]

Bullseye (Debian-based):

Bullseye Pros:

Broader compatibility: Bullseye uses the standard glibc library, making it more compatible with a wider range of Python libraries. This can be easier to set up and maintain. Larger package ecosystem: Debian has a vast package repository, making it easier to find and install most software. Uses apt-get where as alpine uses apk. I have only ever needed to use apk once, and that was to get a video game to run. By the time I finally got it running I was so fed up I immediately deleted it. Because I am in security I feel I must say. Sure, Alpine might get updates a little faster. But Bullseye seems to take security more seriously, and the updates are reliable. If security is a concern which it should be, a zero-day exploit should not be risked for the sake of few megabytes.

Tip:

Multi-stage builds: Consider using a multi-stage build process. In the first stage, you can install all dependencies using the image with a broader package ecosystem (like Bullseye). Then, in the second stage, you can copy your application code into a smaller Alpine image, achieving a balance between size and compatibility.

Alpine cons

Compatibility issues: Some Python libraries might have compatibility issues with Alpine due to its use of musl libc (alternative C library) instead of the standard glibc. This can require additional work to ensure everything functions properly. Less familiar package ecosystem: Alpine uses the apk package manager, which might be less familiar to developers accustomed to Debian-based systems like Bullseye. Smaller community: because of it’s smaller community you can spend your time wrestling with obscure compatibility issues because you went with some minimal image that nobody writes libraries for? Alpine uses musl libc? People are jokingly comparing it to “compatibility muscle strain”. Stick with Bullseye's glibc, because it just works.

Closing

Unless you're building a fleet of servers for a swarm of mosquitos, use Bullseye. It's stable, it's familiar, and it just works. You'll thank me later.

[fyliu]

@drakeredwind01 I get the feeling some of that was AI-generated. It stresses that Debian and alpine use different c libs. at the same time it suggests copying Debian-built binaries into Alpine, contradicting itself.

[drakeredwind01]

@fyliu i did use some ai to help me but I did research it. I don't understand why someone would do this since space is cheap (maybe they have huge databases). but I did see evidence of this in a few articles I don't fully understand yet that is in my "to read" folder. https://www.reddit.com/r/debian/comments/sy45jz/do_you_use_debian_on_production_or_in_enterprise/ among a few others. I personally don't think this is a good idea and will always ask for the more robust option but if your hearts are set on alpine (which i don't recommend) I wanted to show that I conceded it is a possible option (although ill advised). this is the reason I made my site using django and am willing to bang my head against a wall to get it working. but I do beg who ever it may concern not to switch to alpine after reading the heart aches of people who are using it. edit 1 I used Gemini but only as a research tool, corroborated that with peer-reviewed sources, then came to my own conclusions.

[fyliu]

The size difference is actually considerable. It’s an order of magnitude: 100MB+ vs. 1000MB+. Until recently, I had slow broadband internet so it took a while to download and build the image. Since we have contributors from all over at hackforla, I think we should consider that a few of them might get a bigger benefit from smaller downloads than we do.

Graphviz is one of those bulky softwares that added something like 30% to the alpine image size. The recent version of material for mkdocs is another one for including a bulky dependency. I was able to get the image below 100MB by omitting a couple things. But I decided to leave them in so the images are functionally equivalent.

In contrast, a Debian image starts out at 4-5x the size before we even install anything we need. Sure, it provides more packages, but Alpine also provides all that we need, so I don’t see that as a clear advantage of Debian. It may be the embedded programmer in me thinking this, but we also have the option of compiling any dependencies Alpine or Debian doesn’t provide binaries for. In embedded, we start with a basic Linux and a small c lib, and we cross-compile the software we need for running the appliance. So I’m pretty happy that Alpine provides so many binaries.

I did read all the advice for people starting with docker to use a full Linux distribution. I did that for a while here. Then I realized I’m not afraid to compile code from scratch if necessary. But I don’t have to do that with Alpine. It seems to have everything we require so far.

[freaky4wrld]

Logging this error in the PR which I got it while testing the alpine switch changes

=> ERROR [web stage-0  7/10] RUN   --mount=type=cache,target=/root/.cache   pip install uv==0.1.15   && uv pip install --system -r requirements.txt    12.5s 
------                                                                                                                                                        
 > [web stage-0  7/10] RUN   --mount=type=cache,target=/root/.cache   pip install uv==0.1.15   && uv pip install --system -r requirements.txt:                
1.271 Collecting uv==0.1.15                                                                                                                                   
1.984   Downloading uv-0.1.15-py3-none-musllinux_1_2_aarch64.whl (10.1 MB)                                                                                    
7.358      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 10.1/10.1 MB 1.9 MB/s eta 0:00:00                                                                         
7.394 Installing collected packages: uv                                                                                                                       
7.516 Successfully installed uv-0.1.15
7.516 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
7.599 
7.599 [notice] A new release of pip is available: 23.0.1 -> 24.0
7.599 [notice] To update, run: pip install --upgrade pip
10.38 Resolved 47 packages in 2.64s
12.44 error: Failed to download distributions
12.44   Caused by: Failed to fetch wheel: cffi==1.16.0
12.44   Caused by: Failed to build: cffi==1.16.0
12.44   Caused by: Build backend failed to build wheel through `build_wheel()`:
12.44 --- stdout:
12.44 running bdist_wheel
12.44 running build
12.44 running build_py
12.44 creating build
12.44 creating build/lib.linux-aarch64-cpython-310
12.44 creating build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/recompiler.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/backend_ctypes.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/vengine_cpy.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/pkgconfig.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/vengine_gen.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/_shimmed_dist_utils.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/api.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/error.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/cparser.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/setuptools_ext.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/verifier.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/cffi_opcode.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/__init__.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/model.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/commontypes.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/_imp_emulation.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/lock.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/ffiplatform.py -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/_cffi_include.h -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/parse_c_type.h -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/_embedding.h -> build/lib.linux-aarch64-cpython-310/cffi
12.44 copying src/cffi/_cffi_errors.h -> build/lib.linux-aarch64-cpython-310/cffi
12.44 running build_ext
12.44 building '_cffi_backend' extension
12.44 creating build/temp.linux-aarch64-cpython-310
12.44 creating build/temp.linux-aarch64-cpython-310/src
12.44 creating build/temp.linux-aarch64-cpython-310/src/c
12.44 gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -DFFI_BUILDING=1 -I/usr/include/ffi -I/usr/include/libffi -I/root/.cache/uv/.tmpIwAwAp/.venv/include -I/usr/local/include/python3.10 -c src/c/_cffi_backend.c -o build/temp.linux-aarch64-cpython-310/src/c/_cffi_backend.o
12.44 --- stderr:
12.44 No working compiler found, or bogus compiler options passed to
12.44     the compiler from Python's standard "distutils" module.  See
12.44     the error messages above.  Likely, the problem is not related
12.44     to CFFI but generic to the setup.py of any Python package that
12.44     tries to compile C code.  (Hints: on OS/X 10.8, for errors about
12.44     -mno-fused-madd see http://stackoverflow.com/questions/22313407/
12.44     Otherwise, see https://wiki.python.org/moin/CompLangPython or
12.44     the IRC channel #python on irc.libera.chat.)
12.44 
12.44     Trying to continue anyway.  If you are trying to install CFFI from
12.44     a build done in a different context, you can ignore this warning.
12.44     
12.44 warning: build_py: byte-compiling is disabled, skipping.
12.44 
12.44 error: command 'gcc' failed: No such file or directory
12.44 ---
------
failed to solve: process "/bin/sh -c pip install uv==0.1.15   && uv pip install --system -r requirements.txt" did not complete successfully: exit code: 2

Getting this error on Apple Mac M1

[freaky4wrld]

Logging the working solution suggested by @fyliu

• The new alpine shift is failing for Mac users specially for Apple's own chipset
• The solution is to add platform: linux/amd64 to the compose file under the web section, which do help in building the image, as per the stack overflow article suggested by @fyliu
• We are not choosing to make changes to the Dockerfile as @fyliu thinks that the mac users could from time to time try to build it natively on the command line.

[fyliu]

I think I might do a DR page for this since the decision needs some explanation and there are trade-offs.

[fyliu]

Converting this to draft to work on documentation.

• how to convert to Debian
• how to get around Mac missing compiler error
• description of Alpine

[dmartin4820]

I ran this on my local machine and had no issues building and running it. Using uname -a, this shows is what I'm running on: 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[fyliu]

@dmartin4820 sorry, I meant alpine is the best choice right now and we should make the switch with this PR, but we should maybe revisit this decision after we deploy the initial version.

[dmartin4820]

@fyliu Accepting the changes. I added to the meeting agenda for this week an item about creating a task to revisit the change later