Uploaded byChris Riley ☁
Enterprise Docker Requires a Private Registry
The document discusses the necessity of a premium private Docker registry for running Docker in production environments, citing challenges associated with public registries such as governance, trust, and integration. It emphasizes the need for features like consistency, governance, high availability, and integration with the software supply chain. The presentation also outlines the capabilities of Nexus Repository Manager as a solution for hosting, proxying, and managing Docker images.
More Related Content
Similar to Enterprise Docker Requires a Private Registry
More from Chris Riley ☁
Enterprise Docker Requires a Private Registry
- 1. RUNNING DOCKER INPRODUCTION? A PREMIUM PRIVATE REGISTRY IS A MUST
- 2. FEATURED SPEAKERS CHRIS RILEY,DEVOPS ANALYST Coder turned DevOps Analyst at Fixate O’Reilly Author, Content Contributor Nexus Product Manager JEFFRY HESSE, PRODUCT OWNER @HoardingInfo @worduuuuuuuup @sonatype
- 3. 3 Is Docker Readyfor the Enterprise? @sonatype
- 4. 4 Public Container Registries •Don’t build it yourself • Leverage the community • Open source – We love open source! @sonatype
- 5. 5 Challenges with PublicRegistries • Lack of governance • Can’t trust the images • Performance and availability • Where to put your images? • Hard to integrate with software supply chain @sonatype
- 6. What’s Not New •Development is just manufacturing • And a Docker image is just another part in your software supply chain @sonatype
- 7. 7 The Enterprise Needsa Private Registry/Repository @sonatype
- 8. 8 Challenges with PaidDocker Registries & Docker / Distribution Git • No user interface • Isolated tool • Just a bucket • Not built for your supply chain @sonatype
- 9. 9 A Strong PrivateRegistry is a MUST Be Local and Shareable Allow Consistency Have Built in Governance Have High Availability Integrate with the Supply Chain @sonatype
- 10. SHARED User Interface Heterogeneous Organization Searchand Metadata @sonatype
- 11. CONSISTENCY Which Version AreYou Using? One System of Truth Faith Based Deployment @sonatype
- 12. Ensure Identical Environments 12@sonatype
- 13. GOVERNANCE Role Based ImageAccess Able to Store Private Info Avoid Duplication @sonatype
- 14. PERFORMANCE Average 3 MinPull Adds Up More Builds Period Why Pull Everything? @sonatype
- 15. INTEGRATION Directory Services Orchestration Release Automation OtherRegistries @sonatype
- 16. Source Repository Design Build Component Performance System Performance Manual Test Environment Deployment App Staging Environment DeploymentApp Production Environment Deployment App Local Dev. Environment @sonatype
- 17. DOES NEXUS CHECK THEBOX? @sonatype
- 18. 18 Demo: What arewe Going to Show? @sonatype • Nexus 3 Docker Private Registry Capabilities • Docker Push / Pull, Browse and Search • Proxy of Docker Hub • Nexus Groups • Nexus Security via Roles • Hosting binaries too
- 19. Docker: Hosted, Proxy,and Group Repositories 19 Hosted Your Docker Images 1 Hosted 3rd party Docker images Proxy External Docker registry 1 Hosted Your Docker Images 2 GROUP1 GROUP2 Proxy External Docker registry 2 GOOGLE CONTAINER REGISTRY DOCKER HUB NEXUS REPOSITORY MANAGER Development Operations External Developers First
- 20. TRY IT NOWbitly.com/nexusanddocker The Only Free Repository Solution with Docker Support @sonatype
- 21. RUNNING DOCKER INPRODUCTION? A PREMIUM PRIVATE REPOSITORY IS A MUST
Editor's Notes
- #17 This ability to package and distribute containers from your development laptop, onto my laptop, or onto different test, staging or production environments, on-premises and in the cloud, and have them run identically is Docker's functional breakthrough. This eliminates, or makes it easier to diagnose, potential environment conflicts that are a major source of friction between development and operations in a software delivery organization. However, operating Dockerized applications in their own production environment will challenge many enterprises because it requires additional and more sophisticated system management, security and administration expertise than existing (VM and bare-metal) approaches. Governance Challenges: Stating that Docker is an enabler (and possibly even a forcing function) for adopting DevOps practices is easier said than done. An important question of trust arises between Dev teams and production operations. Questions that define the traditional working relationship between Dev and Ops are always asked, such as: Do I trust your software package has no bugs? Do I trust you have used secure coding practices? Can I trust you have profiled this application so that it uses resources efficiently? Can I trust your choice of base container image? How do you know that image is what it claims to be? Can I trust that you have not baked secrets, such as production passwords or private SSH keys, into layers of this container you want me to run? Conversely, the developer creating the container is also taking on responsibility for keeping the containers updated with OS, language runtime and middleware patches (consider the action required for updating images for the Heartbleed or Ghost vulnerabilities). In the most extreme case, Docker's ease of use (democratization) for containers enables developers to circumvent traditional production governance. Trusting Docker images: Gartner discovered 840 Redis images on Docker Hub. Which one should you choose? Searching for MySQL images returns 23 pages of results. How can you know the provenance of those images beyond the bare information you get in the Docker Hub user profile? This is the function of the "Official" tag on a Docker repository in Docker Hub. What does Official really mean? This is an image that Docker Inc. has verified comes from the "owner" of a particular software package, or OS distro. The "Official" Redis Docker images come from the upstream maintainers. Two possible mitigations for this issue exist. One is never accepting an untrusted third- party binary Docker image and always building from a Dockerfile, Chef recipe or Ansible playbook. The other is ensuring you use images from Official repositories that are optimized for particular software. Issues around identity, authorization, trust and image provenance are on Docker's road map, based on public key cryptography, as described at DockerCon Europe in December 2014. This ability to package and distribute containers from your development laptop, onto my laptop, or onto different test, staging or production environments, on-premises and in the cloud, and have them run identically is Docker's functional breakthrough. This eliminates, or makes it easier to diagnose, potential environment conflicts that are a major source of friction between development and operations in a software delivery organization. However, operating Dockerized applications in their own production environment will challenge many enterprises because it requires additional and more sophisticated system management, security and administration expertise than existing (VM and bare-metal) approaches. Governance Challenges: Stating that Docker is an enabler (and possibly even a forcing function) for adopting DevOps practices is easier said than done. An important question of trust arises between Dev teams and production operations. Questions that define the traditional working relationship between Dev and Ops are always asked, such as: Do I trust your software package has no bugs? Do I trust you have used secure coding practices? Can I trust you have profiled this application so that it uses resources efficiently? Can I trust your choice of base container image? How do you know that image is what it claims to be? Can I trust that you have not baked secrets, such as production passwords or private SSH keys, into layers of this container you want me to run? Conversely, the developer creating the container is also taking on responsibility for keeping the containers updated with OS, language runtime and middleware patches (consider the action required for updating images for the Heartbleed or Ghost vulnerabilities). In the most extreme case, Docker's ease of use (democratization) for containers enables developers to circumvent traditional production governance. Trusting Docker images: Gartner discovered 840 Redis images on Docker Hub. Which one should you choose? Searching for MySQL images returns 23 pages of results. How can you know the provenance of those images beyond the bare information you get in the Docker Hub user profile? This is the function of the "Official" tag on a Docker repository in Docker Hub. What does Official really mean? This is an image that Docker Inc. has verified comes from the "owner" of a particular software package, or OS distro. The "Official" Redis Docker images come from the upstream maintainers. Two possible mitigations for this issue exist. One is never accepting an untrusted third- party binary Docker image and always building from a Dockerfile, Chef recipe or Ansible playbook. The other is ensuring you use images from Official repositories that are optimized for particular software. Issues around identity, authorization, trust and image provenance are on Docker's road map, based on public key cryptography, as described at DockerCon Europe in December 2014.