 Hi everyone, welcome to Harbor of Nintendo Track Talk, and today we have Harbor of Nintendors here. We have quite a few model year session. Let's have a quick around self introduction first. My name is Yan, I'm a software engineer at MIR-MIR, the modern application business unit, and I have been working at Harbor for about four years. How have you passed to you, Stone? Hello, I'm Stone, Harbor of Nintendo from Wimwell. I've been working at Harbor for four years. Next, Seung-Wan. Hi everyone, my name is Seung-Wan and I joined Wimwell nearly a year ago. I am a harbor maintainer and I also take the responsibility of maintaining the Harbor Helm project as well. In today's video, I'm going to present the Harbor 2005 recap and course and demonstration. And Vadim, please introduce yourself. Yes, hello everybody. My name is Vadim Babur. I'm one who is not working for VMware. I'm working for a company, and we are providing Harbor as a service. And recently I became a maintainer of Harbor, and I'm happy to give an introduction about what's coming up or coming next in Harbor for the 2006 and beyond releases. Okay, thank you. So this is the first time to attend the Harbor talk. Harbor is a registry for hosting your container images on MCHARS and other OCA compatible things. So we can install these images and we can scan these images with scanner software and you can sign your images. Besides that, we are the graduate project in CSF. And you know, our mission is to be the most secure, performant, scalable and available cognitive repository for Kubernetes. And it's the open source project in GitHub. And if you are interested in the thing that we have been working on right now, issues, discussions, designs, and things like that, they can go to our repository page. And there is Go Harbor.io. It offers the deployment guide, installation guide, and the feature description. You can start with this website or you can start with the GitHub issues if you have any questions and comments. So Harbor is a container registry on top of distribution. Let's take a look at our core tenants. We offer a lot of different features. Here are the key themes. You can have multi-tenancy with using Harbor project. You can have role-based access control with various roles in Harbor today. And you can control this with authentication back-end service, local DB or OIDC or LDAP. Lots of policies are available in Harbor for managing your artifact. So you can set quarters for different projects. And you can also set retention policy to control how long to retain certain artifacts in your project before they are deleted. And you can also lock down your repositories by using immutable tag so that image cannot be overwritten by push or tag and things like that. Artifact distribution is referring the ability to remove artifacts from one registry to another. And the target registry could be another Harbor instance or third-party registry, cloud registry. So you can set the repetition policies for those. Policy cache allows you to use Harbor to process and cache immediate from a target registry, for example, like Docker Hub. There's a big theme around the security and compliance. We allow scanning images. We allow scanning images. And you can also set the CV allow list. Last is the extensibility. We allow users to deploy Harbor within your own infrastructure and make compatible with existing investments. I'm going to stop here now. Change over to Shen Wen to talk about the 2.5 release in details. Okay. So there are two parts regarding Harbor 2.5 recap. One is about the new features being introduced in 2.5. And the other one is improvement being made in 2.5. In the first part, let's start talking about improvement that have been made in 2.5 first. To improve the performance, we implemented concurrent pull requests by synchronously updating artifact pull time and repository pull count. And then garbage collection is now failure tolerant, which means it can continue to delete in subsequent artifacts when removing the current artifact errors out. The next two improvements are the support of skipping artifact replication in a classic cache project and the ability to move often files from the upload directory. And lastly, Harbor is now built using Golden version 1.17.7. In the second part, let's talk about the new feature in 2.5, which is mainly about integrating Harbor with Cosine. We will have a demo on this Cosine integration later in this session, but let's talk about some details of it now. Firstly, Harbor users might be interested in how Cosine signature is stored in Harbor. The Cosine signature is essentially an OCI compatible artifact stored in Harbor as an accessory, which is associated to the subject artifacts and can be deleted independently. Although the accessory is an OCI compatible artifact in essence, there are some limitations on it. For example, Cosine accessory cannot be scanned in Harbor. Secondly, it is about integrating Cosine accessory with tag retention. I would like to emphasize that the Cosine accessory cannot exist independently from a subject artifact, which means whenever the subject artifact is deleted via web UI or through tag retention, the corresponding Cosine accessory associated to it will also be deleted. And this is how Cosine accessory is integrated with tag retention, which means Cosine accessory will be removed when its subject artifact is deleted by tag retention. Thirdly, I would like to talk about how Cosine accessory works in garbage collection. When a Cosine accessory is deleted via web UI or through tag retention, the Cosine signature data is still physically stored in the backend registry storage occupying some disk space. The physical storage will not be released until a GC job is completed successfully. Fourthly, I would like to bring your attention to Cosine accessory with Harbor replication functionality. Since the Cosine signature is an accessory associated to a subject artifact, in most user scenarios, we would like the association relationship being replicated over to the destination registry whenever, either during a push-based replication or a pull-based replication. And that is how Cosine accessory integrates with Harbor replication functionality. In other words, the Cosine signature will be automatically replicated over to the destination registry as an accessory of its subject artifacts. Next slide, please. And in this page, we have some slides in terms of Cosine integration, such as the support to store Cosine signature as an accessory in Harbor, the support of automatically replicating artifacts signature to another Harbor instance, and policy enforcement to disable poorly an unsigned image from Harbor. Additionally, we have an image on the right to illustrate a visual conception of how Cosine works in Harbor. Lastly, if you are interested in more details about Cosine integration, we would like, we have a link to the bottom, at the bottom to Cosine integration proposal. That is pretty much all I would like to share in Harbor 2.5 recap. Thanks. So now I will pass to Stone to have something about 2.6. Hello, I'm Stone. Let me introduce the Harbor 2006 client items. First of all is the performance. Harbor is already widely used in production environment. The performance becomes a critical issue in some scenarios, such as replication and high-concurrent poor request. As Yen already mentioned, we have already found and fixed some performance issue in 2005. And the improvement work will continue in the next release. We found that there are many queries executed repeatedly in a single poor request. These queries could be cast. The catch layer will be implemented in a manager layer. Catch data in manager layer make it still work on whatever data processing layer it used. We could leverage the same catch layer for Postgres or Mexico. The catch layer will be helpful to improve the performance under high-concurrent poor request. The second item for performance improvement is to add an index. For example, we have found that the task table has a job ID column which has no index. And it often leads to a portable scan. To create our index in the job ID could improve the performance. The next example is the audit log table. It becomes huge in some environment. The audit log has no index on project ID. But for each project, there is a log tab. It usually takes a long time to query. And it says there is no response in UI. We will find all queries with performance issues and check if it will trigger a full table scan and consider an index to match some query conditions. Because too many index might also bring some side effect. We will verify the performance improvement carefully with performance tests. The second item is the system artifact. As we know, everything stored is artifact. Could we move to the next slide? The command image and the hand chart are artifact. System artifact is something related to the system. It is a framework that could be used to share data between different services. Let's talk about the system artifact from its user case. We have image scanning service which could scan image and view CVE report. Because it might contain thousands of CVEs we found. The report might be huge. Should we move to the previous slide about the system artifact? The CVE report download should be asynchronous. We adopt the service to run it. It will export the CVE report in a file. Where should we store this file so that we could consume a hub core? Should we store it in database? It might bring some performance issue to the database. Should we store it in persistent volume? It will also impact the scalability of the job service part. Finally, we consider use the registry storage to store these sort of files. And name these sort of files as system artifact. In future, we could extend it to any file needed to store. The third item is the audio log. Could we move to the next slide? Yeah, the third item is the audio log. As we mentioned before, the audio log grows fast in high-concurrent poor-request environment. Sometimes, it might reach 15 gigabytes. Any operation in such huge table will be slow. And also consume the outer database. We consider the audio log table records periodically and forward the audio log to external log service, such as log inside, log stash, or any log processor tool which could handle this log event. When you enable the audio log to the external log service, it is possible to disable write an audio log to database. Use could select either forward to external endpoint or write it to database. Or both of them. Besides performance, could you please let the next slide? Besides performance and audio log, we are going to do some research work on the az registry use case. We have received some age requirement on different channel. For different use cases, for age use cases, the user might require a lightweight harbor. It may have some basic function on harbor, such as RBAC, processing cache, and replication, but with less CPU and memory or bandwidth footprint. Another use case is how to bootstrap our Kubernetes cluster in air gap environment. That's all we have planned for 2006. Thank you. Hi, Seth. So now I will turn it over to Shengwen to have a demo about harbor integrals with cosine to sine and major. Shengwen, please. Hi, there. In this video, I'm going to demonstrate the major new feature of harbor 2005, which is cosine integration. We have already set up a harbor 2005 instance before this demo. The first thing I would like to show you is how to use cosine CLI to sine an OCI artifact and how the cosine signature is stored in harbor so that the harbor user can have a better understanding on cosine accessory. Now, let's push an artifact to harbor. And we can see that the sine by cosine icon is not checked. If we enable deployment security configuration for cosine, which means only allow verified images to be deployed, then Docker pool will be failed to fetch the image that was pushed by us a moment ago. It is failed. Now we can use cosine CLI to sine this artifact. And we can see that the sine by cosine icon is checked now. And now if we do a Docker pool, it will be successful. And by the way, the scan functionality is also disabled for cosine accessory by design. If we do a scan, we can see only the subject artifact is scanned. The accessory artifact is not scanned. And we can delete the accessory individually if we want. Okay, that's the first part. The second thing I would like to show you is how cosine accessory behaves when doing a tag retention. To do that, we need to first create a tag retention rule. We have already created one like this, matching RPI repository, exclude tag 2.6. The expected behavior is that both the RPI artifact and its associated cosine accessory will be deleted together. Let's do an actual run of this tag retention. And the phenomena we can observe here is that both the subject artifact and the cosine accessory are deleted as expected. The third thing I would like to show you is how cosine accessory behaves regarding GC functionality. Okay, after applying the tag retention rule, we can see that both the subject artifact and the accessory are deleted in Harbor Portal, but let's check the registry storage. This is the back end of the Harbor registry instance. And we can see that the actual registry data of BLOPS and MANIFEST still exists in the physical disk of back end registry storage. And they will not be released until we successfully run a garbage collection job. Let's run a GC job. And let's check the GC logs. We can see that there are some BLOPS and MANIFEST are deleted in the GC log. And let's switch to the Harbor instance back end. And we can see that the registry back end is cleaned, which means the disk space has been released. The next thing I would like to bring your attention is how cosine signature is integrated with replication. So we have another Harbor instance setup already, 137. We know that there are two types of replication in Harbor. One is push-based replication, and the other one is a pool-based replication. Essentially, the cosine accessory will be replicated over to the destination registry together with the subject artifact, no matter it is a push-based replication or a pool-based replication. We need to push the artifact and the cosine accessory to the current registry first. We need to push the artifact first and then send the artifact. Okay, let's talk about the push-based replication first. We have already set up a replication registry endpoint before the demo like this Harbor 137. And we have already created a push-based replication rule like this push-based source destination registry 137. And prior to apply the push-based replication policy, we need to make sure that the destination doesn't contains the artifact. There is no artifact under the project, under the library project. And then let's trigger the push-based replication. It is successful. And we can see that both the subject artifact and the cosine accessory have been replicated over to the destination registry as we desired. And then we can use cosine CRI to verify this cosine accessory in the destination registry. We can see that it is validated. Next, we let's talk about the pool-based replication. Pool-based replication, then we need to delete the artifact from the current registry first. And we have already created a pool-based replication rule. Already, using the pool-based default registry is 137. And let's trigger these pool-based replication. And we can see that both the subject artifact and the accessory are replicated from the 137 to the current registry pool-based replication rule. And that is pretty much everything I would like to share. Thank you. Okay. And this is the demo for cosine integration. Just for your fantastic demo, let's move to the robot and the community part. Yes. Thank you for the presentation on cosine. As you saw that cosine is a major improvement in container security if we compare it to the previous solutions with notary. This is a major step forward in the container space and container security. But let's focus on the roadmap and then do a recap on what's coming up next. So, Harper is focusing on three major areas. One is improving the core product, improving the quality of the product, fixing bugs and discovering edge cases that need to be fixed. And so, the other area is continuous improvement, improvement new functionality, new features like the harbor at edge. So, there's a major work going on on how to run edge workloads or edge registry and implement this and integrate this with harbor. So, we will see something in the second half of the year, something released. Then the other areas, of course, the day two operations of harbor, including the deployment of harbor on Kubernetes. But also, if you're not aware, there is a harbor operator which allows you to operate harbor and all the surrounding services on with an operator. And so, major effort will be done here as well to improve the quality of the product and make it easier for users to operate harbor, especially for day two. And as I said, there is a major effort in improving the stability of harbor and also improve the performance of harbor. And as thousands of harbor instances are running now for years and years and the storage is growing, the logs are growing, everything is growing. It needs to be done on optimizing the performance of harbor so that harbor can scale and operate. Another area is regarding day two is backup and restore. So, the project is looking into project Valero and how to integrate project Valero with harbor so that harbor can be backed up in a way familiar with people who are already knowing Valero and using Valero in production. So, the other area of improvement, and this is something also for the community, currently harbor supports only Postgres, but there is a major effort going on to support other databases, not just Postgres. And the next desired state is to support MariaDB and MySQL. So, there is an effort going on in the community and if you're interested in participating, we're happy to invite you to join. As I said, harbor is used by hundreds and thousands of companies worldwide and to my knowledge there is over 20,000 instances running and publicly and there is even more instances running behind firewalls and on-prem environments. So, it's a huge user base and it's a huge community, as you can see, we have a lot of contributions from a lot of companies and there's a lot of issues, a lot of tasks going on. So, it's a really active community and we, of course, trying to improve our community and improve working with the community. So, we have multiple ways how you can engage with the community. So, if we go to the next slide, there's two working groups currently going on. One is the, as I said, the database working group. So, if you're interested in supporting other databases than just MySQL, which is currently worked on, you're invited to join the working group and contribute to that if you're interested in having support for another database than just MySQL. There is another working group going on regarding supporting other formats of container images. So, there's the typical format of container images that, you know, everybody knows, is aware of, but there are other formats that are more compact, for example, and allows, allow, for example, a better startup time of container images. So, there is a working group going on and it's quite active, actually, to support this, this format. So, one format is NIDIS, for example, that is a more compact format of image storing. So, you could, you know, pack up more images into your storage. And this will be, is an effort to integrate this functionality into Harbor. Last step, how you can engage with the community. This is going to be the next slide. So, there are four ways how you could engage with the community of Harbor. And the, I think the most easiest one for all developers is, of course, Slack. So, there is a Slack channel on, Link is missing here, but the Slack channel is on the CNCF. CNCF and the channel is Harbor and HarborDef. So, if you have questions, you can join the, the user's channel on Harbor. And if you would like to contribute to the project, and if you have, the, the developer rated questions, you can join the developer channel on the CNCF. And there is also a CNCF mailing list, mostly used for announcements. So, if you want to stay up, stay up to date with Harbor, it's advice to, to join this mailing list. And of course, the same goes for the Twitter handle. It is mostly used for announcement. And, you know, if you want to be up to date with the current release date of Harbor. And last but not least, is our regular meetings on, I think it's every second week on Wednesday afternoon, central European time. You're welcome to join the meeting as a user or as a contributor or as a potential contributor. You can join the, join the meeting and, you know, see for and learn first, first hand, where Harbor is currently standing at. And there is also a special working group meetings that are happening every, another week as well. But when they're happening, you can find it in the, in the community. And also in the, in the Slack channel. So this is the, the best way how we could engage and communicate with the community. That's it from my side. Thank you very much for your attention. And we are now open for questions.