Enterprise Docker Requires a Private Registry
•
1 like•1,008 views
From a webinar I did with Sonatype. In it I discuss the importance of a private registry to make sure Docker adoption is successful and sustainable in the Enterprise.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to Enterprise Docker Requires a Private Registry
Similar to Enterprise Docker Requires a Private Registry (20)
More from Chris Riley ☁
More from Chris Riley ☁ (20)
Recently uploaded
Recently uploaded (20)
Enterprise Docker Requires a Private Registry
- 1. RUNNING DOCKER IN PRODUCTION? 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 Ready for 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 Public Registries • 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 Needs a Private Registry/Repository @sonatype
- 8. 8 Challenges with Paid Docker Registries & Docker / Distribution Git • No user interface • Isolated tool • Just a bucket • Not built for your supply chain @sonatype
- 9. 9 A Strong Private Registry 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 Search and Metadata @sonatype
- 11. CONSISTENCY Which Version Are You Using? One System of Truth Faith Based Deployment @sonatype
- 12. Ensure Identical Environments 12 @sonatype
- 13. GOVERNANCE Role Based Image Access Able to Store Private Info Avoid Duplication @sonatype
- 14. PERFORMANCE Average 3 Min Pull Adds Up More Builds Period Why Pull Everything? @sonatype
- 15. INTEGRATION Directory Services Orchestration Release Automation Other Registries @sonatype
- 16. Source Repository Design Build Component Performance System Performance Manual Test Environment Deployment App Staging Environment Deployment App Production Environment Deployment App Local Dev. Environment @sonatype
- 17. DOES NEXUS CHECK THE BOX? @sonatype
- 18. 18 Demo: What are we 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 NOW bitly.com/nexusanddocker The Only Free Repository Solution with Docker Support @sonatype
- 21. RUNNING DOCKER IN PRODUCTION? A PREMIUM PRIVATE REPOSITORY IS A MUST
Editor's Notes
- 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.