 Hi everyone. Welcome to the Harbor Maintainer Track Talk. So today we have the Harbor Maintainers here. We have quite a few more than our usual session. One of the benefits of a virtual session. So just a quick round of introductions first. My name is Alex Xu. I am a product manager at VMware in the modern application business unit and I've worked on Harbor for about two years. I'll pass over to you, Stephen. Hello everyone. I'm Stephen Zhou. I'm a staff engineer of VMware. I'm a Harbor Maintainer. I'm working on Harbor for nearly four years. Hi, Zemin. Hello. I'm Zemin. I'm from VMware too. I'm a job Harbor team for three years and I'm the Maintainer of Project Harbor operator. Hello. Hello. I'm Chen from VMware AppU and I've worked on Harbor for about four years. So if this is your first time attending a Harbor talk, Harbor is a registry for hosting your container images, your Helm charts, various other OCI compatible images. So we can store these images. We can also scan these images with container image scanning software. You can sign these signatures or sign images. And we really, we've been around for a couple years now. We are a graduate project within CNCF and we're just still aiming to be the best container registry for the cloud native world. So it's an open source project so everything is on GitHub if you're interested in the things that are being worked on right now. Issues, discussions, designs, things like that. You can always go to the GitHub project page. There's also go harbor.io website that has deployment guides, installation guides, lots of documentation. So start with the website or start with the GitHub issue site and if you have any questions or any comments, you'll find ways to reach out to the team here. Next slide please. So Harbor is a container registry built on Docker distribution. We offer a lot of different features. So here are some of the key categories or key themes. So you can have multi-tenancy with using Harbor project as a unit of tenancy. You can have a role-based access control with various roles within Harbor today. And then you can control these with, again, you can control these with authentication backends, be it local DB or OIDC or LDAP. You can hook these up against Harbor and so you can onboard your users and they're automatically permissioned into the projects based on how they're configured on the OIDC or LDAP identity provider. Lots of policies available in Harbor for managing your artifacts. So you can set quotas on different projects. You can set retention policies with control how long the projects are kept in the project before they're deleted. You can lock down projects in your repositories using immutability policies so that images are not accidentally overwritten with pushes or re-tags and things like that. Artifact distribution is referring to the ability to move these artifacts from one registry to another. The target registry could be another Harbor instance or some third-party registry or cloud registry. So you can set replication policies for those. You can add this a proxy for another third-party registry. And there's a big theme around security and compliance. So we allow signing images. We allow scanning images. You can set CV allow lists. Next slide, please. So we have a 2.3 release that came out in June. Lots of different changes you can see here. The big one is the declarative config and we bumped a lot of components. You can read about this on the website. I really want to focus on the things that are working on right now. So can you go to the next slide, please, student? In the interest of time, I want to focus on the things that are working on for the upcoming 2.4. So this is like a roadmap or preview of things to come, either in the next release coming out at the end of October or the one after that. So a couple of themes here. The first one is that we've added open telemetry to the Harbor stack for distributed tracing. So we have logging today. We have telemetry via Prometheus that you can export to your observability stack outside of Harbor. But this is an important capability that allows you to trace a request, a particular request, as it makes its way through Harbor. Harbor is made up of many different components so it can help with identifying bottlenecks and then performance issues. So we have logging and Prometheus for telemetry, but tracing is really sort of the last pillar of observability. I think we evaluated several options since it can Yeager open sensors and when with open telemetry in the end, just as sort of a first step. And we'll talk about that in greater detail later in the deck. The next thing is we're working on supporting cosine and long and we'll talk about that in greater detail. Cosine is an image scanner or image signing software. I'm sorry. And it's really designed for the multi registry world where you need to be able to relocate an image along with this signature from one registry to another. So you need that relationship between the parent image and the signature to persist as you move these about. And the basis for cosine is that the signature is produced as a special OCI image with its own schema. So when you push the image, it pushes the signature as well. And Harbor being that it's an OCI compatible registry is fully capable of hosting these and managing these as well. So this is still very much in flight. The, you know, our thinking here is that, you know, we are very seriously considering it, but we don't have a specific release, you know, in mind for supporting cosine. But it is a design proposal. You can find it in the community repo. If you have any experience here or any comments, definitely feel free to add comments to to the design doc and or reach out to us and you can, you know, come to the community meeting and hear us discuss this. And the last thing I want to touch on is that there's a new version of the Harbor operator, the Harbor operator 1.1 that that's corresponds to Harbor version 2.3. So it is 1.1 with a particular version of Harbor. And, you know, the Harbor operator has been worked on by so many different community members. Just a tremendous effort. This really started as a partnership with OVH cloud, but we've seen so much interest from other community members needing an operator deployment of Harbor. So if you're not familiar with what the operator is as a pattern, you can start with taking a look at the repository, the Harbor operator repository under Go Harbor projects. But essentially, you know, we created a special custom resource for managing the deployment of Harbor itself, right? So that that custom resource has logic that dictates how the various components of Harbor should be deployed and in what order they should be deployed and it takes care of any dependencies. And you can do that. You can choose to do everything in a single full stack deployment or leveraging all the different things that are already packaged in the release that we've put out, or you can you can externalize components. Maybe you have, you know, a database or Redis cache running as a service in your private cloud. You can certainly use those as well. So the 1.1 is, I think it's a lot more mature than the 1.0. We made a lot of improvements to the CRD based configuration and we updated, you know, the versions of the underlying operators for PD SQL and Redis and Minayo to do these versions. So this is really, you know, we view that as the future of the Kubernetes deployment, right? Today, I think most people are still using Helm, but the operator is, I think it's getting more traction and we are, you know, seriously putting a lot of effort into it. So the helm is not going to weigh, it's not going to weigh any, any time soon, but we're going to have both for, for Kubernetes deployments. And so I'm going to stop here and then now turn it over to Deng Qian to talk about tracing in more detail. Okay. As Alex mentioned, that tracing is the last pillar of observability. And with the tracing, we can have a more specific view of the states of Harbour. In the next release, we will enable tracing in three components of Harbour, which is the core Registral Control and the job service. And the core and the job service is two, is the most important component for Harbour. And in ever tracing these two components, we can get more insights of the states of Harbour. And the Registral Control is focused on the GC and we will know the details of GC of each time it's running. And as you can see, the Harbour core will enable the, we're tracing every HTTP request and it also can trace in the transaction. And the database transaction means every, every time you commit a transaction with a database, either where we record the time span of it. And it also will link the log ID to the span. If you find some span is low or you find some error in the span, you can find in the log, check the log with the ID. And the job service will track, also it will track the HTTP request and also it will track the task states and errors. Because when we're running the job service and it is running, the tasks are running in the background and with the tracing and you will see the states of job surrounding. And the Registral Control will also trace in the HTTP request and the details of the GC's garbage collection. And the way we support the tracing back, the tracing back when we support the two characters. The one is Jaeger and the other one is OTLP. And you can explore the data to Jaeger directly. I think Jaeger is a very popular tracing background service. And the OTLP is a protocol defined by open telemetry community and which used to transfer the tracing, transfer the telemetry data, which include the metrics and the tracing. And with this protocol, you can explore the tracing data to every service, that's the priority service or cloud service, which supports the OTLP. If they are not supported, you can use this protocol to explore the data to open telemetry collector. And this component is also provided by the open telemetry community and which supports almost all the tracing services. And I think this is the tracing in the next release. Thank you. For the COSAN integration, artifact signing on the signature verification are security capabilities that you can use to work by the integrity of an artifact. You may know that in a COSAN release, COSAN supports not only that offers a way to digitally sign images, not only an implementation of COS, the update framework, and it is integrated into doc overall for a good experience. However, the limitations are not revealed cause challenges to usability and scalability in multi registry scenarios. Essentially, our users choose to distribute artifact signature to another hardware instance. And COSAN is a part of a six-storey project and provides container signing and verification with OCI registry integrations. The COSAN signatures are stored as a separate artifact in the OCI registry with a weak reference back to the artifact. After the integration, all the other features can be applied to the artifacts associated with COSAN signatures, like generally a hardware supports user to use COSAN to sign an OCI artifact and store the signature in hardware. And the user can view the signatures from UI and manage the signatures in the hardware. And as the so shown in figure, hardware also supports user to replicate artifact signature to another hardware instance. And because of the hardware builds up the relationship of artifact and its signatures, so the signatures are considered not subject to garbage collection. If they are associated with an existing artifact. Last, like what we did for not only hardware provides another security policy to disallow prudence and damage in hardware. This is all for the COSAN integration part. Okay, thanks, Yan. I will continue to talk about something related to the hardware community. The success of an open source project is inseparable from the support of a healthy and stable community. The hardware community has been committed to building an open healthy and transparent community to promote the development of a hardware project. Till now, hardware has got nearly 16,000 GitHub stars and more than 200 commuters are working on it. We have 12 maintainers from five companies. These maintainers are located in China, Europe, and North America. The various statistics shown on the right further illustrate the hardware community is very active and also thriving. Next, I'd like to share something about the work groups that are driven by the hardware community. Work group is a virtual team focusing on a specified topic and delivers features related to the topic by aggregating efforts across all the interested parties. Till now, hardware community has seven work groups already. Some early firm work groups have already delivered many key features, including replication from the replication work group, P2P distribution from the P2P work group, and the pluggable scanner by the scanning work group. Recently, four new work groups were set up. The multiple architectural work group focused on enabling hardware to support multiple CPU architecture, like R and so on. The performance work group focused on continuously improving the hardware performance. The image acceleration work group focused on providing a solution to let hardware support accelerated image from it, like NINDAS, StarGZ, and so on. The operator work group is trying to provide a stable hardware operator to help users achieve better experience of running hardware on Kubernetes. For the hardware operator, I will share more information later. All the work groups are open to everyone and welcome to join and make contributions. Let's dive into more details of the hardware operator. This is the overall architecture of the hardware operator. It describes how the operator works. As we know, hardware registry is composed of multiple components and also requires PCC database, ready sketch, and storage service. Each hardware component is defined with a separate CR and reconsidered independently. These component CRs are owned by the upper CR, Harbor. Harbor CR represents the whole hardware registry. A top CR hardware cluster is designed to let users describe the whole hardware stack they want to deploy, including the Harbor registry itself and its related dependent services. For the dependent services, you can configure the existing service you have deployed or invested somewhere, or require the hardware operator to deploy them into your cluster together with the Harbor registry. Harbor services are exposed to various ingress for accessing. So far, default NDX, Counter, GCE, and ICP ingress controllers are supported. The certifications are managed by a certain manager. Before deploying Harbor, you need to make sure the ingress controller and the center manager are deployed first. With the Harbor operator, you can obtain the key capability, like manage both Harbor registry and its dependent service, support both configuring existing service and all dependent services. Deploy Harbor with the stack matching your real use cases. Deploy Harbor in a scalable and high-available way. And we also cover some D2 operations for you to support some gates of actions. And Harbor also has some good extensibility to support more different vendors of dependent service. The latest 1.1 version was just released last month. You can have a try and the feedback is welcomed. Version 1.2 is ongoing. In 1.2, we will focus on supporting the Harbor version 2.4 and support Kubernetes 1.22. And we will provide multi-operations like security injection or image pottery writing and so on. As long-term goes, the operator or group will continue to do investigation on some strong requirements, such as get back up and restore or manage Harbor related resources with the declarative way. That is CRD-based way. For more details, you can go to the GitHub project page of Harbor operator repo. Now I'm so pleased to invite Zemin Zhang to give us a demo about Harbor operator. This is a demo is a pre-recording video demo. Let me start to play the video. Now we start to demonstrate the installation of Harbor operator. First of all, in order to install Harbor operator, we need to prepare a Kubernetes environment. Currently, we support versions 1.19 to 1.21. Here I'm preparing KNCLAD Kubernetes 1.21 environment. And I have configured the node for mapping for port 80 and the port 143. After we prepare the Kubernetes environment, we also need to install some dependency components before install Harbor operator. Firstly, install third manager. Here I install the version of third manager 1.4.3. The third manager is installed. Then we install ingress. We can install engines ingress or counter ingress. Here I install counter ingress 1.18. And here we also need to patch the counter ingress to ensure that this node port can be exported. Okay, counter has been installed. We can start installing Harbor operator. We will use the latest version 1.1.0 and then install with the manifest YAMLman cert. We can take a look at the installation process. We can be installing Harbor operator Postgres, Redism, and MIIO operator will also be installed automatically. Okay, Harbor operator is installed next. We can install Harbor. We can find our sample YAML from our GitHub. Here we'll use full step sample downloaded. In this field, we can configure such as administrator's password, which is base 64 encoded and the website certificate. And we can modify the DNS name here. We replace it with our IP DNS. Since we are using counter, so we also need to change the ingress controller to counter. Okay, now we install Harbor. We can monitor its installation process. First of all, it will install our dependent components like Postgres, Redism, and MIIO. Now the dependent components are installed. You see, Harbor operator starts to install Harbor's core components and extended components like 3V and notary. At this time, the Harbor's ports are all up. We can take a look at the status of Harbor cluster CR. See, it's already healthy. We can also take a look at the ingress. Okay, let's visit this website. Okay, we can see that the repository is empty now. Then let's first stop locking. Let's push an image. Okay, then we refresh the UI and see here. We can also do a scan. You can see that the 3V has started scanning now. Then let's take a look at Harbor operator data functions. Let's modify the read-only status of Harbor by configuration CR. First, create a YAML. It will configure Harbor read-only. Let's apply it. Let's take a look at the UI again as we refresh it. See, it's in read-only mode now. Okay, that's all. Thank you. Thank you for the demo. Awesome demo. Thank you to me. Okay, if you want to do a collaboration with the Harbor community, there are several ways for you to choose. You can post a message in the Harbor Slack channel or Harbor Desktop channel. You can contact the community via the email group and you can watch the Twitter of Harbor project Harbor. We have bi-weekly Zoom community meeting. You can send the concrete meeting schedule from the community report. There is also a demo environment setup. If you want to have a try, you can go to the demo.bohob.io, register a user and try the Harbor functions. That's all the content of today's session. Thank you, everyone. If you have any questions, you can start to answer us. Thank you. Thank you. We have a couple of office hours as well. If you want to come with any specific questions or deep dive any issues. Thanks, everyone, for attending. Appreciate it.