We think docker and container technologies are great and are here to stay. However, there are concerns about Docker Hub (hub.docker.com) and we want to make sure that if anything happens we can continue to provide docker images seamlessly.
Additionally Docker Hub provides us with very limited information on pulls and we would like to understand more about how images are consumed so we can provide a better service.
As a result we are working in conjunction with Scarf to provide a future proof solution that benefits both us and our customers.
What is Scarf Gateway?
The Scarf Gateway is an open-source service that provides a central access point to the containers and packages you distribute, no matter where they are hosted. The Gateway sits in front of your current registry and seamlessly redirects your download traffic to it, while empowering you with valuable usage data that your registry is not sharing. You gain better observability into how your software is used, putting your project’s distribution and data back in your control.
You can learn more about it by clicking here.
Benefits of using Scarf to host Docker images
- Scarf sits in front of Docker Hub. So we will still push our images to Docker Hub.
- If Docker Hub is ever shut down or has issues we can promptly change where images are pulled from with no change required by end users.
- If we don’t want to stick with scarf.sh we can point our domain directly at our own registry (or even self hosted scarf.sh)
We will also receive more detailed information on pulls which will help us to improve our services. Docker Hub provides us with a vague pull count. For example it says 50M+ instead of an actual number. This makes it hard to be able to visualize growth.
Some of the additional information Scarf will provide us with:
- Region - from geoip, ip’s are not stored by scarf.sh (Click here to know more)
- Operating System
- Container Tags - Allowing us to see if old versions are still being deployed
- Container Runtimes - Let us see the version of Docker or other tooling being used to pull the container
- An improved notion of “unique” downloads
- Cloud provider and/or company information from IP address metadata (Raw IP’s are not being stored or exposed)
How will this change impact our users?
You will be able to continue to pull direct from docker hub if you want. We definitely will not be making you change.
Any place the docker image is referenced as
`rocketchat/rocket.chat`
you can replace with
`registry.rocket.chat/rocketchat/rocket.chat`
From
`docker pull rocketchat/rocket.chat`
to
`docker pull registry.rocket.chat/rocketchat/rocket.chat`
We will be updating all documentation in the coming weeks to use this going forward.
We are sure that there will be lots of questions - and we'll be more than happy to answer them for you. Please ask aroung through this channel.
Frequently asked questions about <anything>
- Digital sovereignty
- Federation capabilities
- Scalable and white-labeled
- Highly scalable and secure
- Full patient conversation history
- HIPAA-ready
- Secure data governance and digital sovereignty
- Trusted by State, Local, and Federal agencies across the world
- Matrix federation capabilities for cross-agency communication
- Open source code
- Highly secure and scalable
- Unmatched flexibility
- End-to-end encryption
- Cloud or on-prem deployment
- Supports compliance with HIPAA, GDPR, FINRA, and more
- Supports compliance with HIPAA, GDPR, FINRA, and more
- Highly secure and flexible
- On-prem or cloud deployment