Into Cloud Foundry
In the middle of 2014 together with Georgi Sabev I started working on a new project inside SAP. We wanted to have Private Docker Registry in SAP HANA Cloud Platform (HCP). But priorities shifted and in the end of 2014 we adopted Cloud Foundry to enable us to add some new features in HCP.
Being part of the Cloud Foundry Foundation, SAP wanted to contribute back and in the same time eat its own dog food. So it was decided that we will learn the Pivotal way by participating the Cloud Foundry Dojo.
Diego
The Dojo was extremely helpful. It allowed us to meet great people in Pivotal and in particular the guys working on Diego.
If you want to know more about Diego you can check Onsi's last year talk on CF Summit. And if this is not enough go see the design notes.
New Project
Being 10 hours away from where the action is (875 Howard), we started implementing a new feature in Diego, aiming to:
In the middle of 2014 together with Georgi Sabev I started working on a new project inside SAP. We wanted to have Private Docker Registry in SAP HANA Cloud Platform (HCP). But priorities shifted and in the end of 2014 we adopted Cloud Foundry to enable us to add some new features in HCP.
Being part of the Cloud Foundry Foundation, SAP wanted to contribute back and in the same time eat its own dog food. So it was decided that we will learn the Pivotal way by participating the Cloud Foundry Dojo.
Diego
The Dojo was extremely helpful. It allowed us to meet great people in Pivotal and in particular the guys working on Diego.
If you want to know more about Diego you can check Onsi's last year talk on CF Summit. And if this is not enough go see the design notes.
New Project
Being 10 hours away from where the action is (875 Howard), we started implementing a new feature in Diego, aiming to:
- guarantee that we fetch the same layers when the user scales an application up.
- guarantee uptime (if the docker hub goes down we shall be able to start a new instance)
- support private docker images (access to them require credentials)
The goals also include:
- enabling the use of private docker images
- highly available backends
- effective image management
How?
We decided to simply cache the docker images in Docker Registry.
Why?
Because by caching the images we can ensure:
- consistent and faster scale-up
- uptime without Docker Hub
- support for private docker images
Private Docker Images
The caching really helps for supporting private images, although this is not obvious.
Normally we need credentials to access Docker Hub and pull the image on every scale-up request. This would mean storing credentials in DB or requiring them on every user request. That is insecure and inconvenient for the users, operators and developers.
We already have the image cached, so can we simply pass the credentials to Docker Hub on staging and then throw them away? Sure - all subsequent scale up requests will not need access to the Hub in this way.
MVP0
The MVP consists of two parts:
- Docker Registry BOSH Release
- Caching support in Diego
To try it locally you need to install CF, then Diego and finally Docker Registry. You may follow the short guide we provide, which will redirect you to Diego readme for CF and Diego installation.
You can check the registry readme on how to push & cache your docker image. The MVP0 requires you to
opt-in for caching of your docking image. That's because we need your feedback about
the feature, before we really make it productive in Diego.
If you are lazy like me and just want to see it in action, watch this full length (1:23) video.
The Docker Registry also provides small test suite to check if the registry works correctly.
CF Summit 2015
Georgi Sabev will present the Docker Registry on the CF Summit 2015. If you want to know more, to get in touch about a bug/feature or buy him a drink, please join the session.
No comments:
Post a Comment