Add miniforge3 simple base image

[yuvipanda]

A slim miniforge3 image, equivalent to miniconda3 but with some
slightly different choices.

• Use ubuntu LTS as base instead of debian
• Keep $HOME clean, so folks can mount volumes into it

Ref conda-forge/miniforge#20

TODO:

• Fully understand shell implications
• Set up automated build
• Set up some simple tests
• Set up automated push on merge and tag

[yuvipanda]

This is currently 286M, compared to 430M for miniconda3

[yuvipanda]

base is now visibly activated for root and new non-root users created.

[yuvipanda]

I'm going to write tests for:

1. Validating that $HOME is as empty as it should be
2. non-root user creation + running works properly

[yuvipanda]

Ok, so the tests I wanted are in now.

How does tagging work for miniforge releases? Is that done manually or automatically? Ideally for miniforge, I'd like automatic releases on miniforge tagging. Maybe that means this should be in the miniforge repo and not here? Happy to move it if that's what is needed.

Excited for this to get going!

[yuvipanda]

I do wanna add a test that checks if (base) is activated even when $HOME is an empty volume with no .bashrc, since that is what happens when you use it in a JupyterHub style setting.

[scopatz]

Why does it matter that it is ubuntu over debian?

[yuvipanda]

The primary reason is that Ubuntu has timed long term support releases (every 2y), while debian does not. When people want to use this base image, but add new packages from apt, it should ideally be as up to date as possible. Longer term, this is more likely with Ubuntu than Debian, primarily because of the release cadence. You can get around this to some extent with using their rolling releases, but that makes reproducibility very hard by default.

Jupyter's docker-stacks base images switched from debian to ubuntu in jupyter/docker-stacks#428 for these reasons. repo2docker (and hence binder) use ubuntu as base default for these reasons as well.

Some of this is definitely personal preference of course, so am happy to move to debian if people would like to - although I'd personally prefer to not!

[westurner]

MAC (Mandatory Access Control) > Implementations:

• Debian: seccomp, optional SELinux w/ incomplete policy set
• Ubuntu: AppArmor, seccomp, optional SELinux w/ incomplete policy set
• Fedora/CentOS/RHEL: seccomp, SELinux in enforcing mode
• Android (aarch64/x86; termux): seccomp, SELinux in enforcing mode

yum:

FROM centos:7
# RUN yum update -y
RUN yum install -y wget bzip2 ca-certificates git && yum clean all && rm -rf /var/cache/yum

dnf:

FROM centos:8
# FROM fedora:32
# ...
# RUN dnf update -y
RUN dnf install -y wget bzip2 ca-certificates git && dnf clean all && rm -rf /var/cache/yum /var/cache/dnf

[scopatz]

All the files here seem to be lacking a single newline at the end

[yuvipanda]

Fixed!

[scopatz]

Thanks for putting this in @yuvipanda! CC @conda-forge/core

[yuvipanda]

Glad to help, @scopatz!

[scopatz]

Thanks @yuvipanda! CC @isuruf and @jakirkham for thoughts

[xhochy]

I like this and would also use it. For efficiency reasons, could we merge all RUN commands into a single layer?

[jaimergp]

This post contains some tips for reduced conda docker images too: https://jcristharif.com/conda-docker-tips.html

[jakirkham]

@xhochy, we already squash all images as part of the build process on CI.

[xhochy]

@xhochy, we already squash all images as part of the build process on CI.

Awesome! @jakirkham I would then merge, any objections?

[scopatz]

We can always improve it later. Let's go ahead and merge 😉

[CJ-Wright]

This wasn't uploaded to the best of my knowledge. It seems it needs an entry in the .travis.yaml to be uploaded

[xhochy]

This wasn't uploaded to the best of my knowledge. It seems it needs an entry in the .travis.yaml to be uploaded

Made a PR at #131