A rock is an Ubuntu-based container image. Rocks are OCI-compliant and thus compatible with all popular container management tools (such as Docker and Kubernetes) and container registries (such as Docker Hub and Amazon ECR). They are built to be secure and stable by design.
Rocks are created using Rockcraft, which in turn uses Chisel to extract the relevant parts of Debian packages needed to form a minimal container image. By keeping rocks small and specific, their exposure to vulnerabilities is minimised.
Although rocks can be useful for anyone using containers, in the Ubuntu Server context they are particularly helpful for system administrators who want to use containers to manage their infrastructure. To find out how to run rocks on your server, refer to our how-to guide. Alternatively, to find out more about rocks and Rockcraft, refer to the official Rockcraft documentation.
Maybe the paragraph explaining the channels could be replaced with a table, showing channel suffix names, and risk level? Then a short example explaining how publishing a new apache2 image would go through the channels.
For the channel explanation, I kind of feel the better place for a table would be the Docker hub page. Honestly the main motivation for explaining them here is because the current table on the Docker hub page was a bit confusing on first read so I thought it might benefit from a prose description here. Some description of the image publishing process would be interesting but I fear itād risk getting out of date quickly, especially with some of the current process ownership changes under way, so better to merely allude to it here and leave it to be separately documented. For similar reasons, the tutorial doesnāt delve into the technicals of building OCI images, though thatās also likely pertinent to the more advanced readers.
Well, originally I thought we shouldnāt even mention these channels here, and I think the only reason we are doing it is because of the beta suffix in the tutorial, right? How about we just use the latest tag, or no tag at all (so it defaults to latest) to keep things simple? Then we donāt have to mention channels and publication workflows.
Well, originally I thought we shouldnāt even mention these channels here
Yeah maybe. Iām curious when the images will be out of beta. Iād really prefer to reference the stable images (even using ālatestā feels like it could lead users towards unexpected volatility.)
While I agree itās useful to show how to pass environment variables to containers, the TZ one isnāt really useful/necessary here. I believe you can mention that youāre just passing it to illustrate the concept.
Another thing really worth mentioning (and using throughout the tutorial) is that you can run docker as a regular user, instead of running as root. All you need to do is add your user to the docker group.
Unfortunately this is not currently valid. The promotion process is still being figured out; Iām sure we will get somewhere very close to what you described above, but currently all of our tags point to the same image when theyāre updated.
To illustrate what Iām saying, this is what currently happens when we build an image on LP (Iāll use apache2 as an example):
LP will upload the image to Dockerhub/AWS and tag it as ubuntu/apache2:2.4-22.04_edge.
We run our script that created new _beta and _candidate tags (as well as latest and edge), using the ubuntu/apache2:2.4-22.04_edge as a base.
Whenever we have to build a new version of the image, LP will overwrite the _edge tag that it creates, and we will overwrite the existing _beta, _candidate, latest and edge tags and make new ones that point to the _edge tag created by LP.
As I said, the ultimate goal is to have a promotion process that is more similar to what you described, but weāre not there yet.
Thanks, Iāve dropped the -e TZ=UTC from this initial example in interests of keeping it simple. The next example of docker run includes a discussion of environment variables and explains this one in particular, so as you say no use/need to include it in this first one.
Another thing really worth mentioning (and using throughout the tutorial) is that you can run docker as a regular user, instead of running as root. All you need to do is add your user to the docker group.
I was deliberate in not using the group setting, but donāt have a firm opinion, so if anyone cares strongly and wants to change it go ahead. I thought it would seem less invasive to not modify group settings if someone was just kicking the tires, however when dockerās being run inside multipass that shouldnāt matter.
Adding the user to the docker group has security implications. In fact, itās almost like granting root privileges to this user, because they will then be able to launch privileged containers. Combined with bind mounts, this grants root on the host system (and Iām sure there are other ways).
This is also warned about in the upstream docs: https://docs.docker.com/engine/install/linux-postinstall/ and https://docs.docker.com/engine/security/#docker-daemon-attack-surface
Actually, we should probably mention this, regardless if we stick to using sudo or group membership.
There is a rich ecosystem of container providers thanks mainstream tools like Docker, and popular container registries like Docker Hub, Amazon ECR, etc.,
I think it might be "There is a rich ecosystem of container providers thanks to mainstream tools like Docker.
I found this page when trying to figure out what a ROCK is, and unfortunately this page doesnāt really mention what ROCKs are or why theyāre different from images hosted on dockerhub or linuxserver.io.
Thanks @samirakarioh , though Iām afraid those pages read a lot more like āweāre going to go build these and weād like helpā and less like āthese are a real thing available today that you can use, and hereās why you want to use themā.
I started this quest when someone asked if https://rocks.canonical.com/v2/_catalog is supposed to be publicly visible and I havenāt yet found anyone who knows the answer. Thereās an odd mix of old posts about ROCKS coming soon and how to build them with rockcraft but if we have a repository of ROCKS that people can contribute to, or that we maintain, etc, I canāt any hints anywhere.
Hi @sarnold. The docs shared by @samirakarioh are the real thing, today. That page alone should be the only entrypoint you need for everything you can do with Rockcraft and ROCKs.
rocks.canonical.com is an internal registry set a long time ago and doubtfully something you should consider as a resource for your use case.
odd mix of old posts about ROCKS coming soon and how to build them with rockcraft
What posts are you referring to?
a repository of ROCKS that people can contribute to, or that we maintain
What you are looking for is the ROCKs Store (the sibling of the Snap Store, but for ROCKs). That doesnāt exist today, nor will it be there in the immediate future. As the OP mentioned, we do have what we call the āubuntuā namespace in public registries like Docker Hub and ECR. Access to this namespace is only granted (for now) to Canonical teams and is curated by my team, via https://github.com/canonical/oci-factory/.