# PSA: ocaml/opam2 docker images updated to 4.08.0 release
**URL:** https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948
**Category:** Ecosystem
**Tags:** opam, ci
**Created:** [June 18, 2019, 1:53pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948 "2019-06-18T13:53:40Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [June 18, 2019, 1:53pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/1 "2019-06-18T13:53:40Z")
The Docker images hosted at [ocaml/opam2](https://hub.docker.com/r/ocaml/opam2) have now been updated to include the latest OCaml 4.08.0 release as well as the snapshots of 4.09 and 4.10.
One sideeffect of this is that the `ocaml/opam2` default image now has OCaml 4.08 as its default switch. If you use it in CI, it may suddenly give you errors if your code has not yet been ported to work with that new release.
As a reminder, you can pin the OCaml version you use in CI easily by:
- running `opam switch 4.07` as the first command in the Dockerfile after `FROM ocaml/opam2`.
- using the `ocaml/opam2:4.07` image instead of the default one. This image also includes several other 4.07.0 variants (such as afl, flambda and so on), which you can list with `docker run ocaml/opam2:4.07 opam switch`.
As always, please get in touch with me if you see any other breakage from these image updates.
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [July 3, 2019, 12:22am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/2 "2019-07-03T00:22:55Z")
Another update: the base distributions of the ocaml/opam2 images have also been updated to support Fedora 30, Alpine 3.10, OpenSUSE Leap 42.1 and also the impending Debian 10 (Buster) release. We have also deprecated Fedora 27/28, Ubuntu 14.04 and Alpine 3.8 in favour of the newer releases. The 4.09 switches also reflect the recently released 4.09+beta1 snapshot.
There have been a few requests for ‘slimmer’ images that use up less disk-space. The reason the existing ones are so big is that each container has multiple precompiled compilers (either multiple major releases, or feature variants such as flambda or afl). This is really useful for continuous integration, but is less ideal if you just want a quick OCaml compiler container to build some software on your QubesOS laptop.
In order to accommodate both usecases, I’m going to resurrect the `ocaml/opam` containers for the “slim” usecase. The containers in `ocaml/opam` are currently deprecated while we did the opam2 release, but now that is out of the way we can remove the opam1 containers. Over the next few months, we’ll have `ocaml/opam` containers with minimally sized toolchains for production compilation use, and the `ocaml/opam2` containers will continue to be maintained unchanged for CI use.
As always, more feedback or usecases welcome to help guide the evolution of this infrastructure.
---
### Author:  [@Leonidas](https://discuss.ocaml.org/u/Leonidas)
#### Post date: [July 4, 2019, 8:49am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/3 "2019-07-04T08:49:52Z")
Thanks for maintaining the images! We use them for CI (and then start from the respective base image to make deployment images, which given Dockers support for multi-images is pretty nice).
> [@avsm](#):
>
> As always, more feedback or usecases welcome to help guide the evolution of this infrastructure.
As a small sidenote, maybe some renaming would be useful, otherwise it is very confusing that “opam2” is the “fat” Docker images and “opam” is not OPAM 1.x but rather “slim” OPAM 2 images.
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [July 8, 2019, 10:56am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/4 "2019-07-08T10:56:08Z")
> [@Leonidas](#):
>
> As a small sidenote, maybe some renaming would be useful, otherwise it is very confusing that “opam2” is the “fat” Docker images and “opam” is not OPAM 1.x but rather “slim” OPAM 2 images.
Glad to hear that the images are useful! I agree about the renaming, but it has to be done in very slow motion since there is no support for redirections in the Docker Hub. So my approach has been to deprecate `ocaml/opam` slowly and matching the pace of the opam 1.x deprecation.
In the long term, we can also deprecate `ocaml/opam2` and have `ocaml/opam` be the long term home of the opam packages. Need to think through what the tag namespace looks like. The defaults could be the “slim” images (with no compiler variants), and a `-variants` tag suffix could indicate that the images will be bigger and of more applicability to CI systems. Other ideas welcome for layouts.
---
### Author:  [@osener](https://discuss.ocaml.org/u/osener)
#### Post date: [July 8, 2019, 2:34pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/5 "2019-07-08T14:34:36Z")
I find these Docker images very useful as well, thank you! I’ve been using opam2 Alpine variant in multiple projects for statically linked release builds, and Ubuntu in another one, with great success.
A slim variant would be pretty handy. Most of the time I switch to the upstream opam repository and create my own switches, and don’t really utilize what comes bundled in these images.
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [July 8, 2019, 6:25pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/6 "2019-07-08T18:25:24Z")
> [@osener](#):
>
> A slim variant would be pretty handy. Most of the time I switch to the upstream opam repository and create my own switches, and don’t really utilize what comes bundled in these images.
One existing solution to this are the intermediate `-opam` images which are built before opam-repository and ocaml are installed:
```auto
docker pull ocaml/opam2:alpine-3.10-opam
```
These just have the `opam` binary installed and the build tools for that OS necessary to compile OCaml. You could, depending on your CI, switch to the upstream opam repository and create your own switches and cache the result without pulling down the fatter images.
---
### Author:  [@Leonidas](https://discuss.ocaml.org/u/Leonidas)
#### Post date: [July 9, 2019, 9:39am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/7 "2019-07-09T09:39:15Z")
Since we’re discussing it: can you point out where the Dockerfiles of the `opam2` repo are? I was trying to figure out which respective base images they use but couldn’t find them at all. The old Docker repo had a link to a Github repo but for the new one there is no pointer on where to go.
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [July 9, 2019, 12:55pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/8 "2019-07-09T12:55:50Z")
They’re all generated out of a GitLab CI pipeline:
- [https://gitlab.com/ocaml-platform/ci/blob/master/.gitlab-ci.yml](https://gitlab.com/ocaml-platform/ci/blob/master/.gitlab-ci.yml) is where it starts
- this autogenerates the opam containers for all distros (using [https://github.com/avsm/ocaml-dockerfile](https://github.com/avsm/ocaml-dockerfile)) and pushes the outputs to [https://gitlab.com/ocaml-platform/opam-containers](https://gitlab.com/ocaml-platform/opam-containers)
- once the opam containers are built, we generate ocaml containers for them, which are pushed to [https://gitlab.com/ocaml-platform/ocaml-containers](https://gitlab.com/ocaml-platform/ocaml-containers)
- an example pipeline at the end of the road is [https://gitlab.com/ocaml-platform/ocaml-containers/pipelines/69841152](https://gitlab.com/ocaml-platform/ocaml-containers/pipelines/69841152)
---
### Author:  [@Leonidas](https://discuss.ocaml.org/u/Leonidas)
#### Post date: [July 9, 2019, 1:26pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/9 "2019-07-09T13:26:59Z")
Thanks, that’s very useful. I need to check out GitLab CI at some point, too.
---
### Author:  [@talex5](https://discuss.ocaml.org/u/talex5)
#### Post date: [August 9, 2019, 10:54am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/10 "2019-08-09T10:54:04Z")
I’ve also been working on a newer (experimental) pipeline here: [https://github.com/talex5/ocaml-base-images](https://github.com/talex5/ocaml-base-images)
This might make it a bit easier to see everything in once place, since the whole process is coordinated by a single OCaml process, rather than by generating Git commits that trigger more builds elsewhere.
---
### Author:  [@dmbaturin](https://discuss.ocaml.org/u/dmbaturin)
#### Post date: [August 10, 2019, 10:25pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/11 "2019-08-10T22:25:24Z")
Is there one with the +static+musl flavor or an easy way to make one?
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [August 12, 2019, 10:07am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/12 "2019-08-12T10:07:25Z")
What platforms do you need `+static+musl` on? If you’re in a Docker container, then this can be accomplished by using the existing alpine images and adding `-static` to the dune-workspace file.
E.g. something like
```auto
FROM ocaml/opam2:alpine
RUN echo "(lang dune 1.11)" > dune-project
RUN echo "(name duniverse)" >> dune-project
RUN echo "(lang dune 1.11)" > dune-workspace
RUN echo "(env (_ (flags -cclib -static)))" >> dune-workspace
RUN opam exec -- dune build @install
```
This will build static binaries with musl, since Alpine Linux uses musl as its base libc.
---
### Author:  [@talex5](https://discuss.ocaml.org/u/talex5)
#### Post date: [August 12, 2019, 2:36pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/13 "2019-08-12T14:36:40Z")
Ah, that’s useful! However, this did remind me to add some other compiler variants to the pipeline, so there are now images such as:
- ocurrent/opam:alpine-3.10-ocaml-4.08-afl (for fuzzing)
- ocurrent/opam:alpine-3.10-ocaml-4.08-flambda
etc
---
### Author:  [@rbjorklin](https://discuss.ocaml.org/u/rbjorklin)
#### Post date: [September 10, 2020, 5:59pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/14 "2020-09-10T17:59:44Z")
Not sure this is the right place to reach out but the images haven’t been updated since the release of 4.11 have they?
---
### Author:  [@avsm](https://discuss.ocaml.org/u/avsm)
#### Post date: [September 14, 2020, 8:24am UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/15 "2020-09-14T08:24:07Z")
A few infrastructure problems have blocked the update of the ocaml/opam2 images (the Docker Hub basically refuses to let us delete images).
There are up-to-date images under [https://hub.docker.com/r/ocurrent/opam/tags](https://hub.docker.com/r/ocurrent/opam/tags) which are up-to-date and are slimmer (that is, they do not include all the variants of a compiler in a given image, as ocaml/opam2 did).
I’ll post here when I figure out how to fix ocaml/opam2 sensibly…
---
### Author:  [@rbjorklin](https://discuss.ocaml.org/u/rbjorklin)
#### Post date: [September 14, 2020, 4:46pm UTC](https://discuss.ocaml.org/t/psa-ocaml-opam2-docker-images-updated-to-4-08-0-release/3948/16 "2020-09-14T16:46:53Z")
Thanks for responding @avsm!
> [@avsm](#):
>
> the Docker Hub basically refuses to let us delete images
Given that Docker Hub is a central point for most people using Docker this seems like a very reasonable approach from them as others might have built and deployed things into production based on images and tags that have been published.