Universal Developer Image

[l0rd]

/area registry

Which functionality do you think we should add?

Devfile is a specification for containerized development environments. Such environments need to have a minimal set of command line developers tools.

For that reason we should define an image (the universal developer image) used by the devfile registry containers.

Describe the solution you'd like

Here is a list of tools required in the universal developer image

base terminal tools

Tool	ubi8 based image
bash	bash
bat	<gh releases>
curl	curl
diff	diffutils
emacs	NOT AVAILABLE (fedora only)
fish	NOT AVAILABLE (fedora only)
gh	<gh releases>
git	git
ip	iproute
jq	jq
htop	NOT AVAILABLE (fedora only)
less	less
lsof	lsof
man	man
nano	nano
netcat	NOT AVAILABLE
netstat	net-tools
openssh-client	openssh-clients
ripgrep	<gh releases>
rsync	rsync
scp	openssh-clients
screen	NOT AVAILABLE
sed	sed
socat	socat
sudo	sudo
ss	NOT AVAILABLE
ssl-cert	NOT AVAILABLE
tail	<built in>
tar	tar
time	time
tldr	NOT AVAILABLE (fedora only)
tmux	NOT AVAILABLE (fedora only)
vim	vim
wget	wget
zip	zip
zsh	NOT AVAILABLE (fedora only)
TOTAL SIZE	411MB (143MB compressed)

languages runtimes and cloud tools

Tool or language	ubi8 based image
--------JAVA---------	-------------------------------------
sdk	<https://get.sdkman.io>
java	<11.0.12-open via sdkman>
maven	<via sdkman>
gradle	<via sdkman>
-------NODEJS--------	-------------------------------------
nodejs	nodejs
npm	npm
yarn	<via npm>
--------GO-----------	-------------------------------------
go	go-toolset
------PYTHON---------	-------------------------------------
python	python39
setuptools	python39-setuptools
pip	python39-pip
------CLOUD----------	-------------------------------------
podman	container-tools:rhel8
buildah	container-tools:rhel8
skopeo	container-tools:rhel8
kubectl	<kubernetes dnf repo>
krew	<gh releases>
helm	<get.helm.sh>
kustomize	<gh releases>
tkn	<gh releases>
kn	<gh releases>
terraform	<releases.hashicorp.com>
docker	<download.docker.com>
docker-compose	<gh releases>
TOTAL SIZE	2.72GB (1.1GB compressed)

Additional context

• OpenShift WebTerminal Tooling
• GitHub actions ubuntu virtual environment
• GitPod base and full workspaces images

[AlexKhotian]

Hey! Should we also include terraform to the cloud section? nit: I assume that jq is a base terminal tooling rather than cloud. Wdyt?

[ErnstHaagsman]

Could we add netstat and ss?

[ErnstHaagsman]

What do we think about man pages? Most Docker images exclude them, but in an interactive session they're pretty useful.

[l0rd]

@AlexKhotian @ErnstHaagsman I have included your suggestions to the list (including jq as a base terminal tool rather than a cloud tool).

Now the thing is that I will start doing some tests because don't want the image size to go beyond, let's say, 4GB? For the Red Hat image we will use ubi-minimal. For the vendor neutral we can use debian as base.

[ErnstHaagsman]

I've been asking around a bit more. So far we're also missing: tmux, wget, openssh-client. What do we think about tar?

Now the thing is that I will start doing some tests because don't want the image size to go beyond, let's say, 4GB? For the Red Hat image we will use ubi-minimal. For the vendor neutral we can use debian as base.

Looking forward to seeing the numbers!

[AlexKhotian]

@l0rd Would be great to optimize it for the size as well but without any critical cuts for the CX. Feel free to share a test version of the dockerfile so we can play around as well.

[ErnstHaagsman]

Got some more: sed, scp (included in openssh-client?), screen.

Others that were mentioned, but I'm personally not sure about: rsync, netcat, socat, tldr, sdkman, jenv.

[nickboldt]

I'd also suggest adding skopeo and yq (the python wrapper for jq, not the other one), and 👎 for wget (it's less secure than curl and has a smaller feature set).

Re: having two dockerfiles to maintain (ubi8-minimal for x64, s390x, ppc64, arch64; ubuntu for x64, arch64) ... is there really a need for both?

Could we start with just ubi8 and see if there's actual interest/need in second nearly-identical-but-double-the-maintenance-cost one?

[ArvinB]

Having only one dockerfile is preferred where ubi is a base minimum.

My two cents. I don't see these tools mentioned...

python (base tool)
opm (cloud tool)

[resios]

I would be careful around what repos we use for installing these tools. We should strive to use reputable sources and make sure we verify their authenticity via checksums to avoid supply chain attacks.

[nickboldt]

How many versions of Java do we plan to include in this UBI-UDI image? If more than one, see eclipse-che/che#16851 which might be a prereq for this task.

[justinmk3]

fish, wget, and tldr are very redundant with bash/zsh, curl, and man.

rsync is a great compliment to ssh, and enables powerful automation opportunities.

tmux would be really nice. I would even suggest dropping screen, unless it's a POSIX requirement...?

[l0rd]

I have updated the list including most of the tools mentioned in the comments. I have built 2 images based on the list:

• A base developer image (143MB compressed) with the base tools
• A universal developer image (1.1GB compressed) with languages and cloud tools

I pushed the Dockerfiles and other details in this new github repo: https://github.com/devfile/developer-images

[kadel]

Devfile is a specification for containerized development environments. Such environments need to have a minimal set of command line developers tools.

Yes, but also devfile is highly customized for a specific project or type of project (language/framework).

If I have a Java project, why would I need python and nodejs in my developer image? I'm never going to use them with my Java project.

Another problem that I can see is that the list of the tools that you would like to include in the image can infinitely grow when you try to cover different versions of Java,Go,NodeJS.

[nickboldt]

well, it's either an infinite number of small containers to manage/maintain/update, or it's one all-in-one beast of a container that does everything (but chews up a lot of disk).

This is the back-and-forth see-saw debate that has gone on for 30+ years in software. "Thin" vs. "thick", "server" vs. "client", "on prem" vs. "public cloud" ... you'll never make everyone happy, but you can swing the pendulum back and forth every few years and change the approach ... and the buzzwords... :D

Also there are some projects that require multiple language support in the same env. For example, to build Traefik 2.8.1 you need npm and go.

[justinmk3]

either an infinite number of small containers to manage/maintain/update, or it's one all-in-one beast of a container that does everything (but chews up a lot of disk).

3rd option: capture the common (80%) case with a container that's maybe 2x-4x the size of a minimal container (but 100x smaller than the maximum) but has the most common tools ("java latest LTS", "node latest LTS", ...).

[l0rd]

The Universal Developer Image has been implemented and is used by Eclipse Che and OpenShift Dev Spaces for every samples and as the default image when no devfile is found. We are happy with that and we got positives feedbacks from existing and new users.

I don't think we are going to use UDI in the devfile registry though as that is controversial so I am closing this issue as done.