Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!