About rocks

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.

3 Likes

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.

1 Like

Also a great place to introduce docker ps and docker ps -a, just before showing the removal commands.

Thanks Andreas, I’ve added those points.

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.

1 Like

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.

1 Like

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.)

1 Like

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.

It’s better to use -s when invoking curl here (and elsewhere), just to prevent unnecessary output from polluting the example.

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.

I’ve updated to use curl -s

1 Like

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.

1 Like

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.

1 Like

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.

Thanks! I applied the fix.

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

1 Like

Hey @sarnold

If you want to understand more about ROCKS, you can check these links:

1 Like

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.

I hope this helps frame my confusion. Thanks

1 Like

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/.

I hope this helps.

3 Likes