sandbox
sandbox copied to clipboard
cncf
[Sandbox] Stevedore
Application contact emails
Project Summary
Stevedore is a useful tool for anyone who needs to build and manage large numbers of Docker images, and it can help to improve the experience of building and promoting Docker images at scale.
Project Description
Stevedore is a tool for building Docker images at scale, and it is not intended to replace Dockerfile or Buildkit. Instead, Stevedore can be used in conjunction with these tools to help streamline the process of building and promoting multiple Docker images.
Stevedore simplifies the building of Docker images in a standardized way, with the ability to define relationships between them. It provides a consistent way to build Docker images and its descendant images.
You can build images from multiple sources, including local files and git repositories, and generate automatic tags for semantic versioning.
Stevedore also offers a credentials store for easy authentication to Docker registries and AWS ECR, making image promotion and pushing seamless.
Overall, Stevedore is a useful tool for anyone who needs to build and manage large numbers of Docker images, and it can help to improve the experience of building and promoting Docker images at scale.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/gostevedore
Project repo URL in scope of application
https://github.com/gostevedore/stevedore
Additional repos in scope of the application
https://github.com/gostevedore/gostevedore.github.io https://github.com/gostevedore/demo https://github.com/apenella/go-docker-builder https://github.com/apenella/go-ansible
Website URL
https://gostevedore.github.io/
Roadmap
https://github.com/gostevedore/stevedore/blob/main/ROADMAP.md
Roadmap context
The roadmap could be modified, adapted or prioritized depending on the value of features or the benefits for the community.
Contributing Guide
https://gostevedore.github.io/docs/contribution-guidelines/
Code of Conduct (CoC)
https://gostevedore.github.io/docs/contribution-guidelines/code-of-conduct/
Adopters
No response
Contributing or Sponsoring Org
No response
Maintainers file
https://gostevedore.github.io/docs/contribution-guidelines/maintainers/
IP Policy
- [X] If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
- [X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
Why CNCF?
Why do I want to contribute the project to the CNCF?
By contributing Stevedore to the CNCF, I aim to align the Stevedore project with industry standards and best practices endorsed by a leading organization in cloud-native technologies. CNCF sets the benchmark for cloud-native computing, and being part of it ensures that Stevedore follows established guidelines, ensuring compatibility and interoperability with other cloud-native tools and platforms.
CNCF provides a community of developers, users, and contributors passionate about advancing cloud-native technologies. By contributing Stevedore to the CNCF, I seek to leverage this community to foster collaboration, gather feedback, and drive innovation. Engaging with the CNCF community will enable us to refine Stevedore, address user needs, and evolve it into a more robust and feature-rich tool.
Joining the CNCF offers visibility and exposure to a broad audience of organizations and individuals invested in cloud-native computing. By being part of the CNCF landscape, Stevedore can reach a wider audience of potential users and contributors, accelerating its adoption and establishing it as a tool for building Docker images at scale. Additionally, CNCF's platform and resources will help promote Stevedore, increasing its visibility within the ecosystem.
What value does being part of the CNCF provide the project?
By embracing CNCF's values and principles, Stevedore gains access to a supportive ecosystem that accelerates its development, fosters community collaboration, and promotes its adoption across diverse cloud-native environments.
Being part of CNCF enables Stevedore to progress at a high velocity, supporting aggressive adoption by users. CNCF's ecosystem fosters rapid innovation and facilitates the dissemination of Stevedore to a broad audience, accelerating its adoption and impact within the cloud-native community.
CNCF's commitment to openness and accessibility aligns with Stevedore's values of inclusivity and transparency. As part of CNCF, Stevedore operates in an open and accessible manner, welcoming contributions from a diverse community of developers and ensuring that its technology remains available to all based on open-source principles.
CNCF helps Stevedore achieve and maintain a strong technical identity shared across the projects within the foundation. By aligning with CNCF's technical vision and standards, Stevedore enhances its credibility and interoperability.
CNCF provides Stevedore with clear goals and boundaries, enabling effective coexistence with other projects and guiding the ecosystem towards areas of focus for innovation. Stevedore benefits from CNCF's strategic direction, which helps prioritize development efforts and aligns with the evolving needs of cloud-native deployments.
Why did I choose the CNCF?
I chose the CNCF because it is the leading organization in cloud-native computing, with a strong focus on fostering innovation, collaboration, and standardization in the cloud-native ecosystem. By contributing Stevedore to the CNCF, I believe that the Stevedore project will benefit from the expertise, resources, and community support provided by the CNCF, accelerating its development, adoption, and impact in the cloud-native space. The CNCF's platform and network will help amplify Stevedore's visibility, attract a diverse set of users and contributors, and establish it as a key tool for building Docker images at scale. I am excited about the opportunity to be part of the CNCF community and look forward to collaborating with like-minded individuals and organizations to advance cloud-native technologies together.
Benefit to the Landscape
Stevedore brings significant value to the CNCF landscape by enhancing automation, flexibility, and usability in Docker image management, while also addressing key challenges and providing differentiated capabilities that complement existing projects and workflows within the cloud-native ecosystem.
How will adding this project benefit the CNCF landscape?
Stevedore introduces advanced automation features, such as automating the rebuilding of descendant images and enabling semantic version-aware tagging. By automating these tasks, Stevedore enhances the efficiency of Docker image management within the CNCF landscape, enabling organizations to streamline their CI/CD workflows and accelerate application delivery.
Stevedore offers multiple building drivers, currently including the Docker API and ansible-playbook, providing users with flexibility and choice in how they build Docker images. This versatility enhances the CNCF landscape by accommodating diverse use cases and workflows, empowering users to leverage their preferred tools and methodologies for image building.
Stevedore provides a unified interface for image management, simplifying the process of building, promoting, and managing Docker images. This unified approach enhances consistency and usability within the CNCF landscape, reducing complexity and friction in deployment pipelines and enabling developers to focus on building and deploying cloud-native applications.
What is the differentiator or enhancement this project provides to existing projects, capabilities, or challenges within the landscape?
-
Automated Descendant Image Rebuilding: Stevedore's automated descendant image rebuilding feature sets it apart from existing projects by addressing a critical challenge in Docker image management. This capability enhances the reliability and consistency of deployment pipelines within the CNCF landscape, ensuring that changes to parent images propagate seamlessly to descendant images, thereby minimizing the risk of security vulnerabilities and ensuring compliance with organizational policies.
-
Multiple sources as build context: Stevedore provides the flexibility to use multiple sources as build context, enabling users to build Docker images from various sources, such as local directories, Git repositories, or join multiple sources to create a custom build context. This capability enhances the versatility of Stevedore within the CNCF landscape, accommodating diverse use cases and workflows, and empowering users to leverage their preferred tools and methodologies for image building.
-
Semantic Version-Aware Tagging: Stevedore introduces semantic version-aware tagging, enabling users to tag Docker images based on semantic versioning conventions. This feature enhances the clarity and consistency of image tagging within the CNCF landscape, facilitating version control and dependency management in cloud-native deployments, and ensuring that images are easily identifiable and traceable across environments.
-
Streamlined Image Promotion and Credential Management: Stevedore simplifies the process of promoting Docker images and managing credentials, addressing common challenges faced by organizations in the CNCF landscape. By providing seamless integration with Docker registries, AWS Elastic Container Registry (ECR) and Google Artifact Registry (GAR), Stevedore enhances the security and efficiency of image promotion workflows, enabling organizations to securely manage their containerized applications at scale.
Cloud Native 'Fit'
Stevedore fits within the Cloud Native landscape as a tool for automated Docker image building. It embodies cloud-native principles by streamlining image creation, promoting automation, and offering flexibility in building drivers and contexts, aligning with the ethos of Application Definition & Image Build.
Cloud Native 'Integration'
Stevedore complements CNCF projects like Kaniko and buildpacks.io by offering additional capabilities in Docker image building. While Kaniko focuses on building container images without Docker daemon, and buildpacks.io provides a platform-independent tool for building images, Stevedore adds features like automated descendant image rebuilding and versatile building drivers, augmenting the image-building capabilities within the CNCF landscape.
Cloud Native Overlap
Stevedore overlaps with CNCF projects like Kaniko and buildpacks.io in certain aspects of Docker image building. While Kaniko also focuses on building container images without Docker daemon, and buildpacks.io provides a platform-independent tool for building images, Stevedore shares similarities in its aim to streamline Docker image creation. However, Stevedore differentiates itself by offering unique features such as automated descendant image rebuilding and support for multiple building drivers, providing additional options and flexibility to users within the CNCF landscape.
Similar projects
Similar projects in the CNCF include Kaniko and buildpacks.io, which also focus on Docker image building and management, offering alternative approaches to containerization within the cloud-native ecosystem.
Landscape
No, Stevedore is not currently listed on the CNCF Landscape.
Business Product or Service to Project separation
Given the existence of both a Python library and an R library named Stevedore, we recognize the importance of distinguishing our project from these existing libraries. Our project focuses on facilitating Docker image building and management specifically for cloud-native environments. We plan to achieve this differentiation through clear communication, branding, and documentation, ensuring that users and developers understand the unique value proposition of our project within the cloud-native landscape. By emphasizing our project's focus on Docker image building and management for cloud-native environments, we aim to provide clarity and avoid confusion with existing libraries such as the Python and R Stevedore libraries.
Project presentations
No response
Project champions
No response
Additional information
I initiated this project to tackle a significant challenge I faced in my daily work. Recognizing the potential benefits for others encountering similar obstacles, I chose to make it open-source. Furthermore, I viewed this endeavour as an opportunity for personal growth, driven by my enthusiasm for coding and my eagerness to learn from the collective experiences of the community. Joining this project means contributing to a solution that not only addresses real-world problems but also fosters collaborative learning and innovation.
Aleix, Are there any other open source projects that have adopted stevedore for their images? (looking for end users of the project)
Hi @dims! Thank you for reaching out with your inquiry. As of now, I am not aware of any open-source projects that have adopted Stevedore for managing their Docker images. I am optimistic that by joining the CNCF, Stevedore will gain greater visibility and become a valuable tool for many other users.
I look forward to any further questions or discussions.
As a small note, there are a few packages around docker with the same name. Also outside the container area, OpenStack has one that has widespread usage to manage plugins: https://docs.openstack.org/stevedore/latest/
@apenella just for clarification, following on your answer: """ However, Stevedore differentiates itself by offering unique features such as automated descendant image rebuilding and support for multiple building drivers, providing additional options and flexibility to users within the CNCF landscape. """ Can you expand on the value of having this as a separate project instead of adding the functionality to buildpacks or kaniko?
HI @rochaporto! Thank you for your messages.
Regarding your note, after publishing the project as open-source, I realised it shares the same name with other projects. If it would help to avoid confusion, I am open to considering renaming the project.
About your question, Stevedore is not just about building container images, which many other tools already do very well. Instead, Stevedore focuses on managing the process of building and promoting multiple container images, especially when managing images with parent-child relationships. If you need to build a single container image, Stevedore might not be necessary. However, for teams managing many container images, Stevedore is a valuable tool.
To illustrate this, imagine in your team you have a base image with the OS, from which you build a second image with the Python runtime. From this image, you build several container images, each with a Python application. Every time the base image is updated, Stevedore can automatically rebuild all descendant images and promote them to a registry. Additionally, Stevedore can use different drivers for each image build.
From my point of view, it is best to let each tool focus on what it does best. Expanding Kaniko or Buildpacks to include these features would add complexity and additional responsibilities to them. Kaniko excels at building container images from Dockerfiles within a Kubernetes cluster, and Buildpacks help developers focus on writing code rather than managing container images. These tools centre on container images, while Stevedore focuses on the relationships between container images.
Finally, Stevedore uses drivers to build container images, and tools like Kaniko and Buildpacks can be seen as these drivers.
I hope this clarifies the goals and benefits of Stevedore.
TAG Contributor strategy has reviewed this project and found the following:
- The contributor guide is basic.
- There is currently no written governance
- The roadmap is feature based and appears active
- There is 1 maintainer.
- There has only been one contributor since the beginning of 2023.
This review is for the TOC’s information only. Sandbox projects are not required to have full governance or contributor documentation.
Projectname Review Stevedoor
| Date | Aug 19, 2024 |
|---|---|
| Project Name | Stevedoor |
| TAG | TAG Runtime |
| Presentation | Yes/No |
| Project Leads Presenting | n/a |
| TAG Leadership Reviewers | Danielle Tal |
| Recording | n/a |
| Meeting Notes | n/a |
Project Information
High-level Summary
Covered in the sandbox application - [Sandbox] Stevedore · Issue #94 · cncf/sandbox (github.com)
TAG and Working Group Alignment
This is a general TAG-Runtime and might be suitable also for TAG-App Delivery as it overlaps with a few projects in that domain.
History
Covered in the sandbox application - [Sandbox] Stevedore · Issue #94 · cncf/sandbox (github.com)
Architecture
n/a
Goals & Roadmap
Covered in the sandbox application - [Sandbox] Stevedore · Issue #94 · cncf/sandbox (github.com)
Key Considerations:
Community and Growth
- There is one maintainer, from one org.
- There are no contributions made besides from the maintainer - no issues or other activities.
- I could not find any recording of presentations or meetup engagements that can help to help with outreach.
Release Process, Issues and Testing Infrastructure
Releases · gostevedore/stevedore (github.com)
Alignment / Collaboration / Overlap with Existing CNCF projects in this area / Expectations
Projects Collab / Overlap
Covered in the sandbox application - [Sandbox] Stevedore · Issue #94 · cncf/sandbox (github.com)
Also worth mentioning while Stevedore excels in standardising and managing Docker image builds and promotions. On top of Kaniko and buildpacks.io there might be benefits at examining areas of similarities with those projects:
| Tekton | Tekton is ideal for comprehensive CI/CD workflows in Kubernetes environments, |
|---|---|
| Skaffold | Skaffold is designed for continuous development of Kubernetes applications, handling the workflow for building, pushing, and deploying applications. |
Project Challenges
- There is no link to the community meeting notes/slack/discussions
- There are no feature requests from the community
- There are no issues created which signify community traction
Key Feedback to the Project:
- We recommend having a broader set of maintainers from diverse organisations and not just from one
- We recommend to have more public discussions/forums on what’s the scope of the project
- We recommend that the active project maintainers increase the outreach, adoption and collaboration, get more maintainers and move non active maintainers to emeritus status
TAG Recommendation to TOC:
The project currently lacks sufficient community engagement to qualify for sandbox status. We suggest the project responds to the feedback provided and presents at the TAG Runtime and TAG App Delivery meetings to gather more insights, feedback, and outreach. After addressing the feedback, the project can be reconsidered in the next sandbox review cycle.
Hi team! The CNCF TOC has reviewed your project today, and we would love you to work on the following and reapply in 6-12 months:
- Increase the contribution and community engagement. We would like to see more than 1 maintainers.
- Address feedbacks from TAG reviewers earlier (TAG strategy & TAG runtime)
Thank you again for your interest in becoming a CNCF sandbox project! HTH,
Lin
Hi @xmulligan, @miao0miao and @linsun! Thank you for evaluating Stevedore's proposal and providing your feedback. I appreciate the time you’ve dedicated, and your insights are valuable.
I recognise that the lack of community and maintainers is a significant challenge for the Stevedore project. While I hoped to build a stronger community by joining CNCF, I understand that the project needs more traction and maturity before it’s ready for the CNCF ecosystem.
With only one contributor, I haven’t yet established a clear governance structure, but I realise this will be necessary as the project grows. I also acknowledge the need for more presentations, detailed architecture documentation, and expanded communication channels beyond GitHub issues.
In addition to developing new features, I will focus on these areas in the coming months and hope to return with significant progress.
Thank you very much. Aleix