|
13:44
librasteve_ joined
19:00
timo joined
|
|||
| timo | do we have what we would need to have cro container images again? hub.docker.com/u/croservices | 19:10 | |
| japhb | What do we need? Someone to build and push them? | 19:26 | |
| timo | yes, and probably also access to the organisation on docker hub. i've never pushed anything up there so i don't know what that looks like, exactly | 19:28 | |
| honestly, the building part of the images is probably best done with CI and not manually | 19:30 | ||
| japhb | Oh agreed, definitely. Just didn't know what "what we would need" meant in this case. | 19:33 | |
| timo | though there are a script for bumping cro versions and one for building and pushing all images | ||
| github.com/croservices/docker/tree/main - this is the current state | |||
| one ticket exists to ask for a slimmer base image than rakudo-star, since many modules from there aren't necessary for the majority of cro applications | 19:34 | ||
| (that's a pull request actually) | 19:35 | ||
| japhb | The bump and push scripts only seem to cover a minority of the cro modules, unless some include multiple modules | 19:36 | |
| timo | and a separate issue that asks for alpine as the base. we do have alpine-based rakudo-star, which we don't offer variants of the cro images for | 19:37 | |
| looking at the dockerfiles, it looks like only cro-zeromq is based on rakudo-star | 19:38 | ||
| the other ones are based on ubuntu:kinetic and use rakudo-pkg's automatic deb setup script | |||
| japhb | We're two major Debian releases past bullseye, but the idea is good | ||
| timo | well, yeah, the pull request is from 2021 :D | 19:39 | |
| japhb | I'd be quite happy to go to a debian-slim base | ||
| timo: I know, just saying "Needs to be edited before merge, or at least updated before use" | |||
| timo | right | 19:40 | |
| japhb | Alpine I've had less luck with in general, but it's absolutely a worthy base as long as it's an option, not the only one | ||
| Do you want to take this on? | 19:41 | ||
| timo | weekend is yak time i guess | ||
| japhb | Shave the herd! | ||
| timo | there's not much of a downside to offering a little bit of variety to the images, right? | 19:42 | |
| japhb | Definitely not. And Docker themselves tend to offer most of their official images on your choice of debian-slim or alpine, so doing the same fits well. | 19:43 | |
| (They also have a distroless variant, "DHI: Docker Hardened Images", but they're trying to make this purely an onramp for enterprise sales) | 19:44 | ||
| timo | there's also GHCR and quay.io as alternative container registries | 19:49 | |
| GHCR IIUC is "just" github | 19:50 | ||
| japhb | And each cloud has a container repo as well | 19:51 | |
| Personally I don't really care as long as someone can pull without a login, and the registry security is good. | 19:52 | ||
| I'm even fine with publishing to multiple container repos, so that Docker faithful can feel official, and Docker haters have an alternate (presumably more community-based) option | 19:53 | ||
| And of course, there's the whole "EU would very much like it if they could stop having US companies holding all the useful bits" | 19:54 | ||
| timo | i'm a bit of a podman man | ||
| japhb | Fair enough. But in any case, an alternate container image repo that is run by EU sovereign companies or organizations would be a win. | 19:55 | |
| timo | aye | 19:56 | |
| did you see that AWS has founded a fully owned subsidiary to offer "AWS but europeanly sovereigned"? or something like that? | 19:57 | ||
| root@bf12580c8cee:/# cro services | 19:58 | ||
| Failed to get the directory contents of '/proc/acpi': Failed to open dir: permission denied | |||
| in code at /usr/share/perl6/site/sources/0F4A532CB14DBBA4D88FE2F10C30E93CF9E89A57 (File::Find) line 34 | |||
| :D | |||
| a wild yak has appeared | 19:59 | ||
| japhb | If it's a fully owned subsidiary, it isn't EU sovereign, kinda by definition | 20:01 | |
| (But yeah, I did hear about that. :eyeroll:) | 20:02 | ||
| timo | shhh don't tell anybody! | ||
| japhb | Wild yak! Domesticate it now! | ||
| timo | (the error above just happens because `cro services` looks for any .cro.yml below the current directory, and my workdir was still / in this container) | ||
| typical case of DIHWIDT | |||
| japhb | heh | 20:03 | |
| timo | i'm not sure where to find the absolute best state-of-the-art build-docker-with-github-actions stuff can be cargo-culted from | 20:21 | |
| japhb | That's a good question. I have no idea. I was thinking "What about Docker's own official builds?" but I don't know if it's possible to see the machinery there. | 20:30 | |
|
20:34
librasteve_ left
|
|||
| timo | there's a "generate jobs" workflow that spits out a matrix for the right builds like this: github.com/docker-library/official...1361079127 | 20:40 | |
| github.com/docker-library/official...rkflow#L35 - this is where the generate jobs job lives and it uses a shell script from ... | |||
| github.com/docker-library/official...enerate.sh | 20:41 | ||
| maybe it's simpler from the perspective of github actions to give every repo its own "build and publish a docker image" workflow | 20:59 | ||
| i don't think i have the brainspace for this task today | 21:02 | ||
| japhb | If feel you on that count ... | 21:06 | |
| My brain is making that "starter motor insufficient" sound right now | |||