Introduction to ROCK images

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

@cjdc well my actual use case is trying to find someone who knows about this service and decide if it’s a problem that it’s accessible.

While trying to track this down, I’ve been surprised at how little I could find about ROCKS: what they are, why someone would care to use them, how to find them, etc. Even this post here only mentions ROCKS in the heading and then the sentence:

By the end you’ll have a working knowledge of how to set up a container-based environment using Canonical’s ROCKs.

Thanks

@cjdc well my actual use case is trying to find someone who knows about this service and decide if it’s a problem that it’s accessible.

after a quick search, I’d be inclined to say that this is an alias of image-registry.canonical.com and it might be used by commercial systems and solutions QA. Reaching out to them or IS will probably give you more clarity.


While trying to track this down, I’ve been surprised at how little I could find about ROCKS: what they are, why someone would care to use them, how to find them, etc. Even this post here only mentions ROCKS in the heading and then the sentence:

There are in fact old references to ROCKs (like this post) from before ROCKs were even a thing. I mean, the concept and idea were there, but officially, one can only create ROCKs since April 12 2023. In fact, today, you won’t find any ROCK in the “ubuntu/” namespace on Docker Hub/ECR. Nonetheless, we’ve been working on ramping up awareness and following the official channels to educate users on ROCKs. Your feedback is important as it might indicate flaws in our dissemination strategy. Could you please, if you can recall, trace back your steps and share how and where you’ve tried to find said information?

@bryce maybe this is a controversial comment, but given https://canonical-rockcraft.readthedocs-hosted.com/en/latest/, is it still a good idea to keep this page? Apart from the content duplication, there’s the overhead on your side to keep things (like tech and terminology) up to date. Additionally, from time to time people will still find this page and try to fill the gaps or suggest changes.

If it is important to you to maintain this page, I’d at least suggest adding an explicit note letting users know where to find the full docs.

Finally, my obvious comment is that the actual image depicted in this post isn’t a ROCK :slight_smile:

Thanks for letting us know about the ROCKs docs, @cjdc - we’ll take a look and see what the appropriate way forward is. It would probably be more helpful for you guys if we set up a redirect rather than removing the page entirely, but we can discuss!

1 Like

A redirect would definitely work and be less disruptive to your docs. Let me know if you need any help :wink:

1 Like

I feel that this sentence:

ROCKs are Ubuntu LTS-based container images that are designed to meet cloud-native software’s security, stability, and reliability requirements.

which can be found here. should have been on the answer to “What are ROCKS?”.

I read the entire answer and from what was written there I couldn’t find a clear simple answer. There was a lot of foundational knowledge there, but there wasn’t a clear at all what are ROCKs. It wasn’t clear when you stopped explaining the concept of containers, their usefulness, and when you were starting to define what on top of all that are ROCKs.