Name: kubernetes-harbor
Owner: rcbops
Description: An enterprise-class container registry server based on Docker Distribution
Forked from: vmware/harbor
Created: 2017-10-05 15:35:53.0
Updated: 2017-10-05 15:36:55.0
Pushed: 2018-04-11 19:53:14.0
Homepage: http://vmware.github.io/harbor/
Size: 67252
Language: Go
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This section explains how to create the development environment for developing the integration code for Harbor with Rackspace Managed Kubernetes Auth on Mac OSX. This uses your Docker/Docker Compose only because this is a local dev env. Integration with Kubernetes happens in kubernetes-installer.
Read the Harbor section. Because master is unstable, all development happens in a rackspace-mk8s-auth-release-X.X.X branch which is always based on an upstream stable release branch. The rackspace-mk8s-auth-release-X.X.X branch will need to be rebased onto a new upstream stable release branch as we upgrade to newer releases. This is akin to the “vendor branch” pattern in Git.
The only thing in the master branch is this section of the README just so it's easy to find.
There are a few things you need to do to get a local dev env on Mac OSX going.
Fork this repo into your personal account.
Because Go expects source directories to exist in a set location, you will need to clone harbor to your $GOPATH, like so:
r -p $GOPATH/src/github.com/vmware
clone git@github.com:<my-github-username>/kubernetes-harbor.git $GOPATH/src/github.com/vmware/harbor
GOPATH/src/github.com/vmware/harbor
d remotes for both the upstream repo and the fork repo
remote add upstream git@github.com:vmware/harbor.git
remote add fork git@github.com:rcbops/kubernetes-harbor.git
st the remote branches, fetch the latest rackspace-mk8s-auth-release-X.X.X branch, and create a local tracking branch for it
ls-remote --heads fork
fetch fork rackspace-mk8s-auth-release-X.X.X
checkout --track fork/rackspace-mk8s-auth-release-X.X.X
Create a data dir.
mkdir /data
chown $(whoami):staff /data
The /data dir persists all of the data that the Harbor apps use.
Open your Docker preferences and under File Sharing add dirs /data and /var/log.
Fork and clone the repo kubernetes-auth into your personal account and clone it.
Run it with the dummy backend in the same network as Harbor.
run NETWORK_NAME_BASE=make_harbor
This command creates the following containers:
The auth service is set up using a dummy backend, meaning that it will not perform HTTP connections to a real backend like OpenStack Keystone, which is useful for testing. The result of this is that HTTP calls will always pass.
This section is cribbed from the compile guide. This deploys all Harbor components using your local Docker/Docker Compose. A few changes have been made to harbor.cfg to make this work out of the box.
install GOBUILDIMAGE=golang:1.7.3 COMPILETAG=compile_golangimage CLARITYIMAGE=vmware/harbor-clarity-ui-builder:1.2.7
This command creates all of the Harbor related containers. You can find out more about these containers by reading about the Image Registry architecture.
Open registry.127.0.0.1.nip.io in your browser.
You can login using the username/password combo admin/Harbor12345. Becaue of the way Harbor is designed, the admin user is the one and only user that will use Harbor's own DB for authentication.
To login to Harbor as a user, you first need to create a user/token in the kubernetes-auth dummy backend.
Work through the kubernetes-auth example to create a user and token.
Open registry.127.0.0.1.nip.io in your browser.
The auth service will have returned a token as created in step 2. This token will be used as your Harbor password. It's important to note that since the Auth service has no concept of a Harbor username, you can choose any value when inputting your Harbor username - it will be ignored. The only identifier is the token returned by the Auth service
The code which integrates Harbor with the Kubernetes Auth service lives in the ui component. If you would like to update this and re-deploy, you can use the following commands:
checkout -b my-feature-branch rackspace-mk8s-auth-release-X.X.X
ke your code changes.
redeploy_ui GOBUILDIMAGE=golang:1.7.3 COMPILETAG=compile_golangimage
Check your code changes by tailing the ui.log.
er exec -it harbor-log tail -f /var/log/docker/$(date +%Y-%m-%d)/ui.log
Push your commit(s) and branch as usual.
commit -am "My feature"
push -u
When creating the pull request using the GitHub UI, take care to make sure you've selected the correct fork/branch pairs, like so.
base fork:rcbops/kubernetes-harbor base: rackspace-mk8s-auth-release-X.X.Xhead fork: <my-github-username>/kubernetes-harbor compare: my-feature-branchOnce a new feature or bugfix has been reviewed and merged, the Docker image needs to be rebuilt and pushed to quay.io/rackspace/harbor-ui, like so:
compile_golangimage_ui GOBUILDIMAGE=golang:1.7.3 COMPILETAG=compile_golangimage
-f make/photon/Makefile build_ui DOCKERIMAGENAME_UI=quay.io/rackspace/harbor-ui DEVFLAG=false
er push quay.io/rackspace/harbor-ui:$(git describe --tags)
Update the REGISTRY_UI_IMAGE var in versions.sh of the kubernetes-installer to the result of echo quay.io/rackspace/harbor-ui:$(git describe --tags).
When Harbor does a new release upstream, we may want to rebase our code onto that new upstream stable release branch. There are bound to be a number of conflicts to resolve when doing the git merge step.
?? The steps below are untested since we haven't needed to do this kind of upgrade yet. Proceed slowly and with caution. Update these steps as necessary. ??
fetch upstream
checkout --track upstream/release-1.3.0
checkout -b rackspace-mk8s-auth-release-1.3.0 release-1.3.0
merge rackspace-mk8s-auth-release-1.2.0
push fork rackspace-mk8s-auth-release-1.2.0
Note: The master branch may be in an unstable or even broken state during development.
Please use releases instead of the master branch in order to get stable binaries.
Project Harbor is an enterprise-class registry server that stores and distributes Docker images. Harbor extends the open source Docker Distribution by adding the functionalities usually required by an enterprise, such as security, identity and management. As an enterprise private registry, Harbor offers better performance and security. Having a registry closer to the build and run environment improves the image transfer efficiency. Harbor supports the setup of multiple registries and has images replicated between them. In addition, Harbor offers advanced security features, such as user management, access control and activity auditing.
System requirements:
On a Linux host: docker 1.10.0+ and docker-compose 1.6.0+ .
Download binaries of Harbor release and follow Installation & Configuration Guide to install Harbor.
Refer to User Guide for more details on how to use Harbor.
Slack: Join Harbor's community for discussion and ask questions: VMware {code}, Channel: #harbor. Email: harbor@ vmware.com . More info on partners and users.
We welcome contributions from the community. If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will update the issue when you open a pull request. For any questions about the CLA process, please refer to our FAQ. Contact us for any questions: harbor @vmware.com .
Harbor is available under the Apache 2 license.
This project uses open source components which have additional licensing terms. The official docker images and licensing terms for these open source components can be found at the following locations:
If you need commercial support of Harbor, please contact us for more information: harbor@ vmware.com .