use minimal golang-based https server and scratch instead of apache + ubi8/alpine

[nickboldt]

Is your enhancement related to a problem? Please describe.

Today we have Dockerfiles for the plugin and devfile registry images based on alpine, and yeah, they're small.

But they're incompatible w/ Brew builds.

Describe the solution you'd like

I'd like to suggest that we standardize both containers based on a simple UBI8 minimal image that includes httpd and yq.

Describe alternatives you've considered

I could maintain Dockerfiles to build the registries entirely in downstream pkgs.devel repos, but having ubi8 in upstream would make support and maintenance easier as both upstream and down would use the same images.

Additional context

WIP is here:

https://github.com/nickboldt/containers/tree/master/ubi8-yq (only yq)
https://github.com/nickboldt/containers/tree/master/ubi8-httpd-yq (httpd + yq)

See also:

• Enable filtering of old plugin versions from registry #14112
• Replace dependency on mikefarah/yq build container in favour of kislyuk/yq (python wrapper for jq) #14076

[nickboldt]

Couple improvements I can do already to the above images:

a) delete /tmp/dots after we're done with it (but it's only 7 bytes)
b) install findutils in the image so that find works (as it's needed by most of the .sh scripts in the plugin registry.

fixed in nickboldt/containers@4f68db2

PoC using this upstream image:

https://github.com/nickboldt/che-plugin-registry/blob/airgap-resources/Dockerfile.ubi8

Note the previous issues using have been fixed in this repo:

https://github.com/nickboldt/containers/tree/master/che-plugin-registry-airgap

[benoitf]

IMHO I would still use the smallest image, but have an alternate way of using other docker images for downstream.

alpine image is around 5MB while UBI8 minimal is 90MB

$ docker images alpine --format "table {{.Repository}}:{{.Tag}}\t{{.Size}}"
REPOSITORY:TAG      SIZE
alpine:latest       5.58MB

$ docker images registry.access.redhat.com/ubi8-minimal --format "table {{.Repository}}:{{.Tag}}\t{{.Size}}"
REPOSITORY:TAG                                SIZE
registry.access.redhat.com/ubi8-minimal:8.0   90MB

[nickboldt]

mutters It's not always about the size, you know. :|

If you want an alpine based yq container, there's https://hub.docker.com/r/evns/yq/ but yeah, we could have one that includes BOTH httpd and yq based on Alpine if we want something super tiny and incompatible with Red Hat productization processes.

[nickboldt]

@benoitf what if we provide two dockerfiles for each place where there's currently an alpine one?
Could be either Dockerfile and Dockerfile.alpine or Dockerfile and Dockerfile.ubi8.

WDYT?

I mean I can maintain all the ubi8 based ones in a different repo, but it would be way easier to make sure changes are applied to both if the files live side-by-side, rather than in a codeready-workspaces repo.

cc: @l0rd @amisevsk thoughts?

[nickboldt]

Latest versions of the ubi8-based httpd and yq containers are 105.8M and 49.9M, respectively:

https://github.com/nickboldt/containers/tree/master/ubi8-httpd-yq
https://github.com/nickboldt/containers/tree/master/ubi8-yq

https://quay.io/repository/nickboldt/ubi8-httpd-yq?tab=tags
https://quay.io/repository/nickboldt/ubi8-yq?tab=tags

Sure, it's a bit bigger than Alpine. But not that much more.

[amisevsk]

One roadblock on moving to ubi8 is that there is no easy way to get a ubi8-minimal-based container that runs Apache without issue. It looks like setting this up would require significant configuration and I don't know if we want to be the ones to maintain a ubi8-httpd container ourselves.

Additionally, maintaining a ubi8-httpd container ourselves would require CI and a separate repo to allow it to be used in both the plugin and devfile registries.

[nickboldt]

f we want to be the ones to maintain a ubi8-httpd container ourselves

I thought the plan was to drop httpd in favour of something simpler. I mean we don't need any of the fun features in Apache. We just need a file server.

What about https://gist.github.com/DannyHinshaw/a3ac5991d66a2fe6d97a569c6cdac534 or python equivalent ?

maintaining a ubi8-httpd container ourselves would require CI and a separate repo to allow it to be used in both the plugin and devfile registries.

nods yeah, like we already do for all the anyuid-patched community images for the devfile runtime containers. I don't see the problem. Che 7 is 26 images already. What's one more ? :D

[benoitf]

if you really want to be light, reduce CVE, etc and be agnostic by using scratch images then you should use a single binary http server and not something based on python or nodejs or java. So probably use go or rust http server

[nickboldt]

As long as it's https-friendly, I'm more than happy to use a single-binary https server. Can we NOT use a new language though? Go preferred over rust. I'd prefer python personally but YMMV :)

[nickboldt]

Here's a quick golang based https server:

https://github.com/nickboldt/containers/tree/master/che-plugin-registry-https-go-minimal

It doesn't create an index.json yet or do any of the other yaml parsing. Just wanted to get some +1s if this is the correct approach. @benoitf WDYT?

[benoitf]

@nickboldt AFAIK the from should not be

FROM registry.access.redhat.com/ubi8-minimal:8.0-213

but

FROM scratch

[nickboldt]

Based on ubi-minimal, the image is 97M instead of 136M.

But based on scratch, it's only 6.92M.

Updated: https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/Dockerfile

[amisevsk]

@nickboldt 😮

Since we're just serving files, would it work to just repurpose the builders from the [plugin|devfile] registry and copy the relevant stuff into the slim registry image?

[amisevsk]

E.g. https://github.com/eclipse/che-plugin-registry/blob/master/Dockerfile#L23

[nickboldt]

for your consideration: https://github.com/nickboldt/containers/tree/master/che-plugin-registry-https-go-minimal (now it includes all the yq stuff as a three-stage build:

• rhel7-golang to build the webserver
• ubi8-python + install yq to test and generate plugin reg content
• scratch to include ONLY the webserver binary and web content

[benoitf]

Dockerfile for yq looks extremely complex [1] comparing to existing yq docker images with a simple pip command [2]

[1] https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/Dockerfile#L35-L55
[2] https://hub.docker.com/r/evns/yq/dockerfile

And I'm not sure about certificates. AFAIK we only need ca-certs. HTTPs certificate is managed by ingress controller or openshift routes.

[l0rd]

Let's just have an additional Dockerfile.rhel with httpd

[benoitf]

@l0rd now that @nickboldt has a scratch image it will be even better no ? (A single dockerfile with light image)

[nickboldt]

Missing from my scratch image w/ golang https server:

• clarity on the self signed cert approach: I need an expert to weigh in on what I'm doing and if it's bad

• currently the tiny golang https server doesn't automatically server index.json or meta.yaml or README.md if it finds that in a folder. I don't know how to implement that. Can a go expert help?

• https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/main.go#L41-L53
• https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/main.go#L75-L80

As to the whole "installing yq is hard on ubi, it's so much easier in alpine" screams into the void ok but I have to maintain that code for Brew implementation anyway so why not have it in upstream??

[l0rd]

@benoitf FROM scratch is better but we have a lot of productization issues for 7.3.0 and not a lot of time. We agreed that we would use FROM scratch once we get rid of httpd (the registries are implemented as a web app with a REST API).

[nickboldt]

If someone can help me with making the go code in my minimal https server automatically redirect from / folder to /README.md or /index.json if that file is found, we can flip over to that implementation for 7.3.

@benoitf @davidfestal I'm not a golang expert -- can you provide a PR to fix these?

https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/main.go#L41-L53
https://github.com/nickboldt/containers/blob/master/che-plugin-registry-https-go-minimal/main.go#L75-L80

Also I'm not sure what "And I'm not sure about certificates. AFAIK we only need ca-certs. HTTPs certificate is managed by ingress controller or openshift routes." means in terms of implementation. PR me, please?

[nickboldt]

I've renamed this issue since we also have #14678 for moving the registries to UBI (rhel.Dockerfiles)

[nickboldt]

Slip to 7.4, not required for 7.3 / 2.0

[max-allan-surevine]

@nickboldt FYI working from your original Dockerfile at the top, I was unable to download the jq package from the epel7 repo. Errors about unsupported protocol.
Curl error (35): SSL connect error for https://anorien.csc.warwick.ac.uk/mirrors/epel/7/x86_64/repodata/repomd.xml [error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol]

You may want to add something like :
RUN echo "[system_default_sect]" >> /etc/pki/tls/openssl.cnf
RUN echo "MinProtocol = SSLv3" >> /etc/pki/tls/openssl.cnf

to make this work.
(IMHO this is another good reason not to use the ubi8 images!) But thanks for preventing me wasting ages trying to figure out where to get it from!

[nickboldt]

Thanks @max-allan-surevine -- good tip.

Not sure this is ever going to be implemented. @benoitf @amisevsk wdyt? would moving the registries to a tiny UBI8 based golang-implemented https server be worthwhile in upstream?

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.