We use rsyslog to handle system logs inside docker containers but the version included in Debian 8.0 is old and configuration syntaxes are slightly different.
It would be great if you could upgrade to the latest stable version of Debian.
Thank you.

Currently, the images install libssl1.0.2 as a runtimeDeps whereas libssl-dev is installed as a buildDeps. In fact, this means that Erlang is built with libssl1.1 (default in stretch, libssl-dev resolves to libssl1.1-dev https://packages.debian.org/stretch/libssl-dev).

This is quite misleading, and moreover the 1.0.2 dependency is totally useless.

I was trying out multi-stage builds and wanted to create a generic onbuild image others could use to build their minimal release images.

I think this would be a more appropriate onbuild set of instructions that what current exists:

ONBUILD WORKDIR /usr/src/app
ONBUILD COPY . /usr/src/app
ONBUILD RUN rebar3 as prod tar

ONBUILD RUN mkdir -p /opt/rel
ONBUILD RUN tar -zxvf /usr/src/app/_build/prod/rel/*/*.tar.gz -C /opt/rel

The use of tar is important because of how Erlang target systems are built that changes around a few things from just the built release and use of the prod profile so the user can specify how they want their project built for production.

Then the user can make their Dockerfile (with docker 17.05 and above):

FROM erlang:19.3.3-onbuild as builder

FROM ubuntu:16.04

ENV RELX_REPLACE_OS_VARS true
<any ENV vars they want defaults set of>

WORKDIR /opt/<RELEASE NAME>
COPY --from=builder /opt/rel /opt/<RELEASE NAME>
ENTRYPOINT ["/opt/<RELEASE NAME>/bin/<RELEASE NAME>"]

What do you think?

I suggest we extract out the Elixir Dockerfile to a new repo. This way, the elixir upstream team would define the repo collaborators independently from the erlang project.

Join the discussion at docker-library/official-images#1171

I think if the main image includes rebar3 it should be included with the alpine image as well. Images are usually used for development/building a release to use in another image anyway and thus the user has to manually get rebar3. Plus rebar3 is small in comparison.

I'm having issues downloading the latest image. It might have something to do with the recent changes to support multiple architectures.

$ docker run erlang:20.0.5-slim
Unable to find image 'erlang:20.0.5-slim' locally
20.0.5-slim: Pulling from library/erlang
docker: no matching manifest for linux/amd64 in the manifest list entries.

this could be a problem because of runtime dependencies got uninstalled by apt-get purge -y --auto-remove $buildDeps ; we need someway to pin it in the image

# erl -boot start_sasl -s crypto
Erlang/OTP 18 [erts-7.2.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

=PROGRESS REPORT==== 2-Feb-2016::21:31:53 ===
          supervisor: {local,sasl_safe_sup}
             started: [{pid,<0.37.0>},
                       {id,alarm_handler},
                       {mfargs,{alarm_handler,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

[...]

=ERROR REPORT==== 2-Feb-2016::21:27:10 ===
Unable to load crypto library. Failed with error:
"load_failed, Failed to load NIF library /usr/local/lib/erlang/lib/crypto-3.6.2/priv/lib/crypto:
 'libcrypto.so.1.0.0: cannot open shared object file: No such file or directory'"
OpenSSL might not be installed on this system.
{"init terminating in do_boot",{undef,[{crypto,start,[],[]},{init,start_it,1,[]},{init,start_em,1,[]}]}}

Crash dump is being written to: erl_crash.dump...done
init terminating in do_boot ()
root@e929a7df6074:/#

after apt-get update && apt-get install libssl in this session, it runs ok

The way Erlang images are tagged may induce issues in Erlang/Elixir application releases. Those releases are said to be tied to a very specific version of Erlang, meaning if a release is build with Erlang 21.1 it may not work with Erlang 21.1.1. This is related to the app.rel file listing all the app dependencies, even the OTP ones. For instance, Erlang 21.1 has application ssl-9.0.2, while Erlang 21.1.1 comes with ssl-9.0.3. A release, depending on the ssl application, built with Erlang 21.1 won't work with Erlang 21.1.1.

That said, the erlang:21.1-alpine and erlang:21.1.1-alpine are based on the same Erlang 21.1.1. I've tried to run an application depending on ssl build with Erlang 21.1 in a container based on erlang:21.1 and failed.

IMHO, when a given image is tagged, it's not a good practice to move the tag to another image.

Hi, we are working on an Elixir application that uses jinterface to be able to communicate with Java application. The use case for that is AWS Kinesis that has client library only in Java and thus there is no other choice. This is the Java part: https://github.com/Accenture/reactive-interaction-gateway/tree/master/kinesis-client.

Is there any chance to create official docker image also with Java (jinterface) support? (and perhaps the same for Elixir image)

We would like to avoid checked in jinterface and use it natively from Erlang.

It looks like a good idea to bundle these on the erlang images, just as bundler is bundled in the ruby image.

Somewhere after Linux 5.4 (which is still in use on many LTS releases of distros and on many clouds) the SCTP user space API changed. Alpine 3.13 uses a sctp.h from a kernel with the newer API, preventing Erlang SCTP from working on those kernels.

Builds that use the older SCTP continue to work on newer kernels.

Hello!

Recently our common_test suites started to fail in our (gitlab-runner) CI environment with errors like this:

        {dir_SUITE,init_per_testcase,
            {{noproc,
                 {gen_event,call,
                     [cth_readable_logger,cth_readable_failonly,
                      {ct_pal,
                          [10,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,
                           45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,
                           45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,45,
                           45,45,10,"2018-06-06 19:41:49.002",10,116,101,115,
                           116,32,105,110,105,116,32,39,"bic",39,58,32,68,101,
                           108,101,116,101,100,32,107,101,121,115,32,"[]",10,
                           10]}]}},
             [{gen_event,call1,3,[{file,"gen_event.erl"},{line,207}]},
              {cthr,pal,4,
                  [{file,
                       "/usr/src/rebar3-src/_build/default/lib/cth_readable/src/cthr.erl"},
                   {line,74}]},

As far as I understand the gitlab CI environment and our setup, the CI job fetches the erlang:19 Docker image:

Using docker image sha256:2ea95f0c3147e50b79b4fcd28c955c80c2e57eb20fb8ff61bb8ed1873d0b6957 for erlang:19

and executes our test suite in that image. Our code did not change, but it looks like the image did change, at least at the latest successful test I see this in the logs:

Using docker image sha256:e36b5300c4cf2f504f0222ea66bbf81fb2e514ad88cb93f111b5e85e7893b99a for erlang:19

Do you know what changed?

running the command: docker pull erlang:20 returns no matching manifest for linux/amd64 in the manifest list entries.

Upon inspection with docker manifest inspect erlang:20, you can see that it is not available:

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2010,
         "digest": "sha256:b51cfaa66cbaff81010c1fd9cd5a3786a63e13974f022c32ffa2c2f2fc822a0d",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2010,
         "digest": "sha256:f37d957729f8c72266fb451c14c5cbd810fac12a86e72a2d9323b636071eaffb",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2010,
         "digest": "sha256:0c5e751bda31f42b922d6c093fef91f1a777b9385d5fa3bd5be3854a8c05483a",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2011,
         "digest": "sha256:84183ad190cf770bb5f76b330261791f2cb0d3de1c0d5a890012b8513d789093",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      }
   ]
}

Will this be fixed? I assume that it is not intentional. It is available for erlang:21, but our application is currently not compatible with 21 and we are hoping to continue using erlang:20 on the linux/amd64 platform.

I have a couple of these already build and published here. I could make a PR if there's interest.

since stretch is the alias of new latest of buildpack-deps:latest some other language images already moved on; this isn't priority but nice to have, sooner or late.

however when I had an attempt it resulted an over 1GB docker image for the default developer friendly erlang:latest variant; reason is stretch is 210MB larger than jessie, see docker-library/buildpack-deps#64 hopefully can be fixed upstream.

Last update of elixir:1.5 with erlang:20 broke SSL.

We started getting random {:tls_alert, :bac_mac_record} errors when talking with HTTPS services. Rolling back to erlang:20.2.3 solves the issue.

Seems like the base image is broken as when using apt-get with it you get a lot of errors related to bad ELF files.

Current Alpine images are built with Alpine 3.9.4. When using the image to build OTP releases with bundled ERTS, we noticed that it won't run on Alpine 3.10, exiting with dlsym: Resource temporarily unavailable.

According to this bug it is because of musl changes and just needs a rebuild on a newer musl version. I wasn't able to find anything suspicious in the musl changelog, but swapping erlang:alpine with alpine:latest and installing Erlang from Alpine's repos fixed the issue and now OTP releases built in the container run on both 3.10 and below.

the original goal for this repo was to deliver an Erlang container as close as possible to upstream (https://github.com/erlang/otp/releases) within reasonable image size, it turns out to be the current approach: download source code tarball from upstream, and compile it during building the docker image, this way we can control 3rd party library dependencies as minimum and most often used ones; so that it didn't pull in all java for jinterface, and gtk/gl for wxwidgets (which is a required dependency for observer to start, see observer source code at https://github.com/erlang/otp/tree/maint/lib/observer/src, it is a wxwidgets application.)

Now @AugustoPedraza is requesting to use observer (see c0b/docker-elixir#19 for background), it is totally possible to include gtk/gl for wxwidgets during the compiling; the only question is should we do it? or maintain another variant?

@SDWolf gives another example of using the precompiled packages from erlang-solutions: c0b/docker-elixir#19 (comment)
I was aware of this approach but didn't choose it since the beginning of this project was because they were not releasing as often as today, there was some lags behind erlang upstream, but now in 2016 it seems ok, from erlang-solutions we can get pretty latest once every upstream release, we can have a image size test and it's probably ok to switch

The other approach was to use OS/Distro pre-packages many Linux distros were packaging Erlang very trivial https://packages.debian.org/jessie/erlang and not preferred,
https://packages.debian.org/sid/erlang https://packages.debian.org/jessie-backports/erlang

Please vote here what changes you want to see in the Erlang base image.

I notice all the official images (except slim) include build-essentials.

This is great for development - for production it may however be required to reduce the attack surface.

Regarding slim, I couldn't find the tags on the docker hub? It still builds from source, even though it removes the build-essential packages, is this really necessary?

For production, would it be possible to create a Dockerfile which deploys using the rpm packages?

for example:

FROM debian:wheezy

RUN echo "deb http://packages.erlang-solutions.com/debian wheezy contrib" >> /etc/apt/sources.list \
    && wget http://packages.erlang-solutions.com/debian/erlang_solutions.asc \
    && apt-key add erlang_solutions.asc \
    && apt-get update && apt-get install -y \
    erlang \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

Are there any disadvantages from this approach?

I was curious if the images would be moving to alpine by default or sticking with debian. My understanding was that docker wanted the official images to be alpine based. Is this the case?

I'm wondering if you would consider bumping the git to 2.18 or greater on your images.

The background of this request is that the Github Actions' Checkout action (that's a mouthful!) falls back to checking out via REST API (source: https://github.com/actions/checkout#whats-new) when git version is below 2.18. What this means is that you actually get a snapshot (archive) of your sourcecode rather than all commits, tags, etc.

Github's reasoning is not compelling, but the argument goes that git 2.18 implements support for partial clone via transport protocol v2 which decreases the load on Github's side. There is no way to tell the action to go ahead with a regular clone, despite the presumable higher load on Github, even if it's negligible for small repos.

So for instance in testing jesse on Github Actions with your images, on every run there's a 2-3 minute "waste" installing git 2.18 plus its dependencies (source: https://github.com/for-GET/jesse/blob/master/.github/workflows/ci.yml#L51-L58). In order to remove that waste, it's a question of upgrading git on your images or forking github's action to checkout as usual, just without the partial clone via transport protocol v2.

Thanks in advance!

Hi @getong 👋

Today we have an issue that whenever there is a new minor release, such as 23.0, we can't strictly depend on it. For example, when 23.0.1 is shipped, new deployments pointing to 23.0 will now change to 23.0.1.

While X.Y is meant to be fully compatible X.Y.Z, it may be possible that X.Y.Z introduces a regression, which breaks builds and production apps. Some may also be generally uncomfortable with the idea of depending on a mutable tag.

I also understand this is mostly an issue with Erlang versioning. The initial release is 23.0, which is also the Docker tag for 23.0.X, which leads to this ambiguity. However I believe it would still be desirable to address this problem. One simple solution would be to also publish 23.0 as 23.0.0, 23.1 as 23.1.1, and so on. What do you think?

Thanks for the time and for maintaining these images!

HI,

I'm trying to build an application which relies on

/usr/local/lib/erlang/lib/ssh-4.7.6/src/ssh_sftpd.erl

to be present. However, in the alpine builds, that file is unfortunately missing. This is the error I'm getting trying to build my app:

== Compilation error in file lib/channel.ex ==
** (RuntimeError) error parsing file /usr/local/lib/erlang/lib/ssh-4.7.6/src/ssh_sftpd.erl, got: {:error, :enoent}
    (elixir) lib/record/extractor.ex:84: Record.Extractor.read_file/2
    (elixir) lib/record/extractor.ex:50: Record.Extractor.extract_record/2
    lib/channel.ex:8: (module)
    (stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
could not compile dependency :sftpd, "mix compile" failed. You can recompile this dependency with "mix deps.compile sftpd", update it with "mix deps.update sftpd" or clean it with "mix deps.clean sftpd"

The base image I'm using is elixir:1.8.1-alpine which in turn depends on elixir:21-alpine.

Thanks for any hints.

I'd used docker-machine(version 0.6.0, build e27fb87) and docker on Windows 10 (1511), try to

docker run -it --rm erlang

then I got

cannot enable tty mode on non tty input

docker version

Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 21:49:11 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 21:49:11 2016
 OS/Arch:      linux/amd64

@getong I'm opening this as a note in case I miss the future PR when 23.1 is released.

Discussing in the Build and Packaging Working Group led to the conclusion that the smallest change necessary to get others on board with using these images instead of duplicating work and causing community confusion would be to add that final .0 to the version when a minor release is made. Also for a major release, meaning when 24 comes out the tags would be, 24, 24.0 and 24.0.0.

I realized I don't really know how the different versions are pushed and tagged. It is a manual process with a PR to add a new tag, like 23.1.0 and then how does it know to create 23 and 23.1 as well?

The generate-stackbrew-library.sh script outputs all the tags like:

Tags: 23.0.2, 23.0, 23, latest
Architectures: amd64, arm32v7, arm64v8, i386, s390x, ppc64le
GitCommit: ed3bd9400e1b72b2bdd08596990f8ed3350a75c0
Directory: 23

But travis only builds, it does not push, and then runs that official-images/test/run.sh with the image name/tag of the image built.

I don't see a push in that test script either but may have missed it if its calling out to other scripts in their official-images repo.

On a side note, we can move the manual process part to be a a github action as part of the erlang/otp repo. But we can worry about that after this.

See c0b/docker-elixir#131

tldr; phoenix with brunch with sass uses brunch-sass, which uses node-sass, which doesn't support nodejs 12 apparently, so it doesn't support alpine 3.11 (yet) because alpine 3.11 only has nodejs 12 in the apk package repo

It seems to me that updating the base image to alpine:3.11 this shortly after the 3.11 release (12 December) is overly aggressive. When looking at https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases it seems that alpine 3.10 is still supported until May 2021, so it seems there is no reason for this update at this moment. It would seem prudent for an image like erlang:22, which has so many dependent images, to take a slightly more conservative approach.

I just found a comment on the docker hub page https://hub.docker.com/_/erlang/

radupopescu 18 days ago
Hello,
Would it be possible to enable dirty schedulers for 19, 19.1, latest images?

and researched somewhat for benefits why need dirty scheduler and how to do that

https://news.ycombinator.com/item?id=11064763
https://hamidreza-s.github.io/erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html

http://erlang.org/doc/installation_guide/INSTALL.html#Advanced-configuration-and-build-of-ErlangOTP_Configuring

--enable-dirty-schedulers - Enable the experimental dirty schedulers functionality. Note that the dirty schedulers functionality is experimental, and not supported. This functionality will be subject to backward incompatible changes. Note that you should not enable the dirty scheduler functionality on production systems. It is only provided for testing. This switch also imply --enable-new-purge-strategy (see below).

the good news is this feature would be an easy one https://github.com/c0b/docker-erlang-otp/blob/master/19/Dockerfile#L24 just need some sanity check before releasing in the new way of building 19+ images

(generally a github issue for feature request is preferred over docker hub comment, because hub.docker.com doesn't have comments notification and many other features as a discussion board should have)

some minor version is missed in tags
such as 21.2.0, 21.1.0
current tag 21.2 is pointed to 21.2.1
current tag 21.1 is pointed to 21.1.4

cause erlang app release in docker 21.2 which deps on erts-10.2.1
but some server side preinstalled erlang only contains erts-10.2

I was trying to use the 24-slim image and I'm getting this error:

Step 4/4 : RUN set -eux;   rebar3 eunit --cover;   rebar3 cover --verbose;   rebar3 compile
 ---> Running in 1bac7b7d1be2
+ rebar3 eunit --cover
/bin/sh: 1: rebar3: not found
The command '/bin/sh -c set -eux;   rebar3 eunit --cover;   rebar3 cover --verbose;   rebar3 compile' returned a non-zero code: 127

The exact same Dockerfile definition file, if used with -alpine or just latest works fine:

FROM docker.io/library/erlang:24-slim

WORKDIR /tmp/workspace/

COPY . ./

RUN set -eux; \
  # rebar3 format; \
  rebar3 eunit --cover; \
  rebar3 cover --verbose; \
  rebar3 compile

Is there anything missing in that image?

Logs for -alpine Image

[x80486@uplink:~/erlang_awesone]$ docker build --tag acme/erlang-awesone:latest ./ 
Sending build context to Docker daemon  25.09kB
Step 1/4 : FROM docker.io/library/erlang:24-alpine
24-alpine: Pulling from library/erlang
540db60ca938: Pull complete 
20d61903337f: Pull complete 
Digest: sha256:86a30e8f29e4534261877f55472eeff68d619f90c2dcbc273227d56b72cd16b5
Status: Downloaded newer image for erlang:24-alpine
 ---> bad6285a1962
Step 2/4 : WORKDIR /tmp/workspace/
 ---> Running in ab6a75a0ef7d
Removing intermediate container ab6a75a0ef7d
 ---> 3c0448c27048
Step 3/4 : COPY . ./
 ---> 962a7d9b8008
Step 4/4 : RUN set -eux;   rebar3 eunit --cover;   rebar3 cover --verbose;   rebar3 compile
 ---> Running in dae9c6fb5783
+ rebar3 eunit --cover
=WARNING REPORT==== 21-May-2021::13:58:06.278109 ===
Description: "Authenticity is not established by certificate path validation"
     Reason: "Option {verify, verify_peer} and cacertfile/cacerts is missing"

===> Fetching rebar3_format v1.0.1
===> Fetching katana_code v1.1.1
===> Analyzing applications...
===> Compiling katana_code
===> Compiling rebar3_format
Not formatting the formatter. We're not on the regular compiling cycle
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling erlang_awesone
===> Performing EUnit tests...
......
Finished in 0.054 seconds
6 tests, 0 failures
+ rebar3 cover --verbose
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling erlang_awesone
===> Performing cover analysis...
  |------------------------|------------|
  |                module  |  coverage  |
  |------------------------|------------|
  |           problem_001  |      100%  |
  |           problem_002  |      100%  |
  |------------------------|------------|
  |                 total  |      100%  |
  |------------------------|------------|
  coverage calculated from:
    /tmp/workspace/_build/test/cover/eunit.coverdata
  cover summary written to: /tmp/workspace/_build/test/cover/index.html
+ rebar3 compile
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling erlang_awesone
Removing intermediate container dae9c6fb5783
 ---> 126c0e0e19b9
Successfully built 126c0e0e19b9
Successfully tagged acme/erlang-awesone:latest

Logs for -slim Image

[x80486@uplink:~/erlang_awesone]$ docker build --tag acme/erlang-awesone:latest ./ 
Sending build context to Docker daemon  25.09kB
Step 1/4 : FROM docker.io/library/erlang:24-slim
24-slim: Pulling from library/erlang
d960726af2be: Pull complete 
8bb15c7e621f: Pull complete 
Digest: sha256:cf1bb4e1ad1f291db59598ecdbd56bbcdb002586437e154f1df7644c16790617
Status: Downloaded newer image for erlang:24-slim
 ---> f8d2a5974ee0
Step 2/4 : WORKDIR /tmp/workspace/
 ---> Running in 2b502dfedc99
Removing intermediate container 2b502dfedc99
 ---> b59907cd3942
Step 3/4 : COPY . ./
 ---> 142280b9a04a
Step 4/4 : RUN set -eux;   rebar3 eunit --cover;   rebar3 cover --verbose;   rebar3 compile
 ---> Running in a9530d899a26
+ rebar3 eunit --cover
/bin/sh: 1: rebar3: not found
The command '/bin/sh -c set -eux;   rebar3 eunit --cover;   rebar3 cover --verbose;   rebar3 compile' returned a non-zero code: 127

The steps described here didn't work for me and it took me quite a bit of fiddling and duckduckgoing around to make the observer work on my machine - I'm running OS X v10.12.3 (16D32). Here's a step-by-step description - mostly take from here - that can be added to the README if you feel it'll help people:

• Make sure the version of the docker image of erlang is >= 19.2
• Install XQuartz if not already installed: brew install xquartz (at the time of writing the latest version I installed is 2.7.11)
• Run XQuartz
• Update preferences 'Security' tab - turn on 'Allow connection from network clients'
• Restart XQuartz and then check to see that it is listening on port 6000: lsof -i :6000
• Get your local machine's IP: ip=$(ipconfig getifaddr en0) && echo "My IP is: " + $ip
• In the XQuartz terminal run: xhost + xxx.xxx.xxx.xxx. The output should be something like: xxx.\ xxx.xxx.xxx being added to access control list
• Run the docker container: docker run -it --rm -e DISPLAY=${ip}:0 -v /tmp/.X11-unix:/tmp/.X11-unix erlang

cc #289
In the continuation of the reproducible/immutability idea I suggest also marking Alpine's version in the tag.
e.g. turn erlang:22.3.4.10-alpine into erlang:22.3.4.10-alpine3.10
See e.g. https://hub.docker.com/_/python

Maybe also include the rebar3 version that's bundled with it as well: erlang:22.3.4.10-rebar3.13.2-alpine3.10

We have a dependency on Windows and having support for Windows containers in both Erlang and subsequently Elixir would be very useful.

Is this something that has been considered already? (I had a quick hunt through the issues on this repo and couldn't find much related to Windows but perhaps I'm missing something). Would others find this useful as a PR? We are going to spend some time investigating this in-house but we might have something suitable to contribute if so.

See Docker's Official Images Build Server for details.

Jessie is at end-of-life and should no longer be used as a base for projects.

Essentially, this project should migrate from Debian Jessie to Debian Stretch at your earliest convenience.

We can not run our Elixir apps deployed with distillery in this base Erlang alpine docker image any more.
On application start we keep getting the error:

Could not locate code path for crypto-4.4.2!

Our automated build process always takes the latest version of the erlang:alpine docker image and up until now (with only one exception last year) everything worked fine.

all we do is:

FROM erlang:alpine
MAINTAINER sebisnow
# Default to UTF-8 file.encoding
ENV LANG=C.UTF-8

RUN set -x; \
    apk update && \
    apk upgrade && \
    apk --update add bash && \
    rm -rf /var/cache/apk/*

ENV app=<the_app_to_deploy>
COPY --from=builder /app/_build/prod/ /app

EXPOSE 8080
WORKDIR /app

CMD trap exit TERM; /app/rel/${app}/bin/${app} foreground & wait

How to fix this issue? Or should we just wait for a fix you are working on already?

Found that docker hub page does not include all tags as in tags page.

If an image is not maintained anymore for any reasons, please remove those tags. If they're still maintained, then please add them into description.

Having "undocumented" tags may result in having "unmaintained images", which doesn't get updated and therefore misses security patches on base images. See #147

Why does the alpine install of Erlang have everything removed?

It isn't possible to use it as a base image for building a release the way it is.

I'd also propose adding rebar3 to the image.

When creating a CircleCI Orb I wanted to use the official docker images but it turns out the use of caching in CircleCI requires the image to have ca-certificates installed. Currently the image build will remove it after having installed it for the build.

So every job requires to first install the package. It isn't a blocker of course, https://github.com/tsloughter/rebar3_orb/blob/master/src/orb.yml#L33

But I figured I'd bring it up since I would suspect it is a fairly small package. Yea, it is 196kb.

Can you provide the docker image of arm32v7/erlang:21-alpine as soon as possible in this repository? Thank you

Hi there 👋
I've got a Raspberry Pi Zero, which has an armv6 architecture. Unfortunately, this image only provides linux/arm/v7.
I looked at the build script, and it looks like it would be as easy as adding arm32v6 in there.

Looking at other official images, e.g. python, I see that their script fetches the architectures from here: https://github.com/docker-library/official-images/blob/master/library/python#L19

Maybe that approach could work here as well?

I'm currently in the process of cross-compiling this + the derived elixir image myself to check if it works. But it's taking hours...

The merge of #175 broke the crypto module on tag 19-slim.

Steps to reproduce:

Run:

docker run -it --rm erlang:19-slim erl -s crypto

and you will get:

{"init terminating in do_boot",{undef,[{crypto,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
init terminating in do_boot ()

Wondering if this repo should be maintained by the OTP team.

Could we please get images based on Centos 7?

Hello.

I've discovered that manifest of Erlang image in the Docker official-images repo is pointing to this user: https://github.com/c0b/
https://github.com/docker-library/official-images/blob/ffc1738524f0876757f273af51b40c8130b4bda4/library/erlang#L3

He was the first one who made Docker images for Erlang and Elixir, but disappeared few years ago. Is it correct to still mention this user in a script which generates this manifest file?

Found that https://hub.docker.com/r/library/erlang/tags/ lists images for old Erlang versions, and they haven't been updated for a while.

This will result in missing security fix on base image!

I don't know how all things work together... but
based on https://github.com/docker-library/official-images/blob/master/library/erlang the manifest file is generated by https://github.com/erlang/docker-erlang-otp/blob/master/generate-stackbrew-library.sh

Thoughts on removing the need for https://github.com/c0b/docker-elixir/ by having them handled in this repo? While also expanding the support for OTP versions per Elixir version as brought up in this issue c0b/docker-elixir#122 (comment)

I can get dialyzer to work if I add --no_native however that slows things down a lot and what is more of a problem is that I don't want to change my Makefile to do this everywhere.

Compiling some key modules to native code...{"init terminating in do_boot",{{badmatch,ok},[{dialyzer_cl,hc_cache,1,[{file,"dialyzer_cl.erl"},{line,572}]},{lists,foreach,2,[{file,"lists.erl"},{line,1337}]},{dialyzer_cl,hipe_compile,2,[{file,"dialyzer_cl.erl"},{line,516}]},{dialyzer_cl,do_analysis,4,[{file,"dialyzer_cl.erl"},{line,382}]},{dialyzer,'-cl/1-fun-0-',1,[{file,"dialyzer.erl"},{line,153}]},{dialyzer,doit,1,[{file,"dialyzer.erl"},{line,243}]},{dialyzer,plain_cl,0,[{file,"dialyzer.erl"},{line,84}]},{init,start_it,1,[]}]}}
init terminating in do_boot ()

Is it possible that Dialyzer is broken/mis-packaged in 20.0.5? I use "20" for running Dialyzer on GitLab-CI and this is a new error. I used to run that CI job without issues before, and my local Dialyzer 20.0.5 works as well.

See https://gitlab.com/triqng/triq/-/jobs/33692481 from https://gitlab.com/triqng/triq/pipelines/12039078.

Error in process <0.302.0> with exit value:
{{badmatch,error},
 [{erl_types,type_from_form,6,[{file,"erl_types.erl"},{line,4769}]},
  {erl_types,t_form_to_string,1,[{file,"erl_types.erl"},{line,5286}]},
  {erl_types,t_form_to_string_list,2,[{file,"erl_types.erl"},{line,5301}]},
  {erl_types,t_form_to_string,1,[{file,"erl_types.erl"},{line,5298}]},
  {erl_types,t_form_to_string,1,[{file,"erl_types.erl"},{line,5235}]},
  {dialyzer_contracts,contract_to_string_1,1,
                      [{file,"dialyzer_contracts.erl"},{line,108}]},
  {dialyzer_dataflow,get_apply_fail_msg,10,
                     [{file,"dialyzer_dataflow.erl"},{line,642}]},
  {dialyzer_dataflow,handle_apply_or_call,10,
                     [{file,"dialyzer_dataflow.erl"},{line,562}]}]}

I was build docker-erlang-otp/20/slim/Dockerfile and docker-erlang-otp/20/Dockerfile on arm64 architecture successed. So I want to know that whether or not support arm64 architecture.Except docker-erlang-otp/20/alpine/Dockerfile, because there is some problem.

Hi,
I've added the images for OTP-22 but they are not showing up in Docker Hub.

What step am I missing? There's not much documentation...

Do I need to update generate-stackbrew-library.sh?

Also, is the GitLab-CI integration still used?

Cheers,
LP