Alpine 3.10

[Sherley]

AwesomeI was able to install Pihole on alpine aarch64 with your fork, but I haven't been able get it properly configured. Lighthttpd doesn't seem to be in apk for aarch so I installed Pihole without the web interface. Now I can't get pihole-FTL to start up the dns. If I manually start dnsmasq Was there any extra steps you had to do to set up the dns? I don't necessarily need the web gui.

For me it's working, but there's only one problem: ip -oneline is broken in alpine >= 3.9 and thus the discovery of the interfaces fails. I manually edited /etc/pihole/setupVars.conf to set the PIHOLE_INTERFACE variable.

One issue I ran into is that the blocklist update script (gravity.sh) generates the sqlite input with an extra empty line between each entry, which causes the blocklist update to fail. Installing gnu sed to replace busybox sed fixed this.

Let's take this exercise a bit further. Let's actually make our own Node.js Alpine container. NOTE: I'd suggest always using the official one. They'll keep it up to date with security fixes and they're real good at making containers. Better than I am, anyway. But this is a good exercise for us to go through to learn how to install system dependencies.

Start with this in a new Dockerfile. You can call it my-node.Dockerfile. Some people will insist it should be Dockerfile.my-node but the former doesn't break syntax highlighting and it doesn't matter since Docker doesn't actually care.

alpine:latest would nab you the latest Alpine (3.10 as of writing, if you run into issues with versions, continue with alpine:3.10 instead of alpine:latest. Otherwise feel free to truck on with alpine:latest)

Okay so now if you do docker build -t my-node -f my-node.Dockerfile . it'll build your new image. -t is --tag and -f is --file which is what tells Docker is the name of your Dockerfile you're using (otherwise it assumes you're using a file called exactly Dockerfile.) Now try docker run -it my-node. In here you should have a pretty bare bones Linux container but both node -v and npm -v should work.

Keep in mind that Alpine does not use bash for its shell; it uses a different shell called ash or often just sh. It's similar enough to bash but there are some differences. It's not really the point of this class so we'll keep the focus on learning just what's necessary.

I'm mimicking what the Node.js official container does, which is make a user group of node with one user in it, node. Feel free to name them different things if you feel so inclined. Notice we could conceivably combine the two RUN instructions together but it's generally best practices to keep "ideas" separate. The first RUN installs dependencies, the second one creates the node user. Up to you how you do it, neither is wrong per se.

It works! We're down to 56MB (compared to 86MB with the official node:12-alpine container). Honestly, I'm not entirely sure what we cut out from the other node:12-alpine container but it's probably important. Again, I'd stick to the official containers where they exist. But hey, we learned how to add a user and install system dependencies! Let's make it even small because why the hell not.

Three years ago I published,Rebuilding My Personal Infrastructure With Alpine Linux and Docker,in which I described how I was hosting various applications using an AlpineLinux host and Docker on a virtual machine at Vultr. I thought itwould be good to write a follow-up on how this worked out.

The server I set up in 2019 is still running, although it has been through afew Alpine upgrades in that time. Since there are very few packages installedon the host, upgrades are painless. When I originally configured theserver Docker Compose was not in the stable Alpine package repos. It was addedin the mid-2019 Alpine 3.10 release. I was glad to be able to remove pip andnot have to manually manage compose updates after migrating to the package fromthat point on.

As you can see the server is now running more containers. It now hosts a numberof new services including a Pleroma instance and several web-applications Ibuilt in Rust (leaf, quotes, dewpoint). I also retired the BinaryTrance Rails instance and migrated from acme.sh to lego. I ran a Nitterinstance for a while but removed it after it bots made it consume a huge amountof bandwidth. See my Burning 2.5Tb of Bandwidth Hosting a NitterInstance post for more details onthat.

It turned out that this never worked. I could see that cron was running thescript but the certs would not get renewed. For a while I ran thescript manually to renew them, which did work. Eventually I got sick of this, andthinking acme.sh was to blame I searched for an alternative.

Same error here, trying to build a static executable from the latest alpine docker image, but http/client throws an exception about utf-8 encoding. Any idea about which apk would be missing ? Been trying to investigate the changes in musl-libc, but I found nothing.

This is easy: you can modify iconv.cr directly in your Crystal distribution, or reopen it, copy the initialize method in your program and add debug info there (puts). Same goes with whatever you get from the http client.

During some recent benchmarking work of the Ballista Distributed Compute project, I discovered that the Rust benchmarks were ridiculously slow. After some brief debugging, it turns out that this was due to the use of musl, and this blog post was originally asking for help with the issue, but now provides some solutions.

My benchmark is packaged in Docker and I had used musl to produce a statically linked executable which was then copied into an alpine image, resulting in a small docker image. I did this because it is an approach that I have seen suggested in many blog posts.

I ran some multi-threaded benchmarks on a 24-core desktop using the command docker run --cpus=12 to allocate 12 cores and I expected the benchmark to take 5-6 seconds based on the performance I saw when running natively on my desktop. Instead, the benchmark seemed to run forever (it turned out that it took around 30x longer than expected) and system monitor showed many threads using between 20% and 40% CPU during this time.

Also, some people suggested that the performance problems in musl go deeper than just the jemalloc issue, and that there are fundamental issues with threading in musl, potentially making it unsuitable for my use case.

Given these concerns over musl, I decided to go with a different solution. It turns out that I could use the same multi-stage Dockerfile approach but use debian:buster-slim as the new base image instead of alpine, and this no longer requires the use of musl (because the code was compiled in debian:buster-slim , because that is the ultimate base image).

Sadly, Alpine does not support installing through wheels, so wheels have to be built from scratch. This should not be an issue for small, standalone packages, but quickly becomes a challenge for complex packages like streamlit, with various of dependencies.

Of course there exists Alpine-precompiled packages for numpy (see here), but I do not see any for streamlit, or any other relevant packages. So might be that I will have to build all these myself from scratch.

So it is likely that this path is not worth venturing for anyone who considers using Streamlit with Alpine. Go with Debian instead and wait for Debian to resolve the vulnerability issues observed (and reported) by Snyk.

As for the security issues in Debian (FROM python:3.12-slim), the only High vulnerability I found was with the cryptography library. You can unload that in your Docker build with

RUN apt-get remove -y python3-cryptography

The problem with Alpine, is that 1) there are barely any precompiled binaries which you can install and 2) (even worse) installing these is a huge hassle, as you cannot install wheels, and you can for most other Linux distros.

@JoaoPedroMDP The original question was about installing streamlit on alpine. Sadly pyarrow is only one tiny dependency in the mix of all deps that need to be installed. There is also of interest to install other deps like openai. Even if you manage to install pyarrow I think we are quite far to get streamlit working in Alpine.

As barely any deps are supported on Alpine, I think its going to be nightmare to add support for all. its better to just wait for Ubuntu to add a fix for the vulnerability in the Ubuntu distro, which was the main reason why I at all tried Alpine (as Alpine dont have the same vulnerability built into the distro).

EDIT: I also disagree that py3-pyarrow: The real solution. (...) approach is the proper solution. Sure this is a way to solve the issue with pyarrow, but do you have the same solution for all other deps? Surely not.

These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.

These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.

These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.

These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.

There are considerable benefits of using, building and deploying small container images (small attack surface, faster updates, less network costs ...), and when it comes to lightweight distributions, Alpine Linux is by far the favorite choice.

Busybox is, as stated by its creator Bruce Perens , "The Swiss Army Knife of Embedded Linux". It combines tiny versions of many common UNIX utilities into a single small executable. it provides the core functionalities for dozens of standard programs, such as awk, cp, grep, gzip, sh and top.

3a8082e126