A private Java (Maven or Gradle) repository as a service can be setup in the cloud. A private Docker registry as a service can be easily setup in the cloud. But what if you want to build a holistic CI/CD pipeline, and on the cloud of YOUR choice? In this talk Baruch will take you through steps of setting up a universal artifact repository, which can serve for both Java and Docker. You’ll learn how to build a CI/CD pipeline with traceable metadata from the Java source files all the way to Docker images. Amazon, Azure, and Google Cloud (do you have setup that works on these?) will be used as an example although the recipes shown would be applicable to other cloud as well.

2. whoami
Baruch Sadogursky, JFrog Developer Advocate, @jba

3. Poll Time!

4. Poll Time!
Heard about Docker
Can do the tutorial
PoCing, playing etc.
Production, baby!

9. Docker Workflow

10. Union File System

11. Image Layers - OpenJDK

12. Getting Started with Docker

16. JFrog Artifactory + Docker

17. Who’s using Docker and nothing
else?

20. The Promotion Pyramid
Development builds
Dev Integration tests
Integr. tests
Staging
Pre-Prod
Prod
Amount of builds
Build/Deploytime
Amount of
binaries

21. Pipeline: Quality Gates and
Visibility
Source: Agile ALM, Michael Hüttermann, Manning Publications Co.

22. $docker build

24. Too easy!

26. That’s why.

27. Let’s fix it!

28. Let’s fix it (again)!

29. Let’s fix it (again)!

30. That’s why you don’t trust
Docker

31. Traditional Server Pattern
http://martinfowler.com/bliki/ImmutableServer.html

32. Immutable Server Pattern
http://martinfowler.com/bliki/ImmutableServer.html

35. What’s up with the gates?!

37. What’s up with the gates?!

38. What’s up with the gates?!
- QA shouldn’t test dev images

39. What’s up with the gates?!
- QA shouldn’t test dev images
- non-tested images shouldn't be staged

40. What’s up with the gates?!
- QA shouldn’t test dev images
- non-tested images shouldn't be staged
- non-staged, non-tested or dev images
shouldn’t end up in production!!!

41. Not so fast…

42. Trumped-up limitations

43. The Anatomy of Docker Tag

44. Wait a second, how can I
have more than one
repository per host now?!

45. How can we support this?
https://host:8081/artifactory/docker-dev/busybox
https://host:8081/artifactory/docker-staging/busybox
https://host:8081/artifactory/docker-qa/busybox
https://host:8081/artifactory/docker-prod/busybox

46. “ONE REGISTRY PER HOST OUGHT
TO BE ENOUGH FOR ANYBODY.”

47. Panic!

48. Virtual hosts/ports to the
rescue
https://host:8081/artifactory/docker-dev/busybox
Context name
Virtual repository name
Tag name
https://host:port/v2/busybox

49. server {
listen 5001;
server_name 192.168.99.100;
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/docker-dev/$1/$2;
…
}
}

50. But then you realize…
Wait a second, now I need
to pull, retag and push for
every step?!

53. Anatomy of a container

54. Our Layers
Application:
• .war file
Framework:
• JDK8 + Wildfly
Base:
• CentOS

55. Framework build
- Verified base image
- Add system dependencies from
artifactory
- JDK
- Tomcat
- Own it!

56. Minimal Framework build
Dockerfile
FROM centos:7
MAINTAINER you@yourorg.com

57. Application build
- Framework is your base
- Run a java build
- Add a file to base
- Done!

58. Application build Dockerfile
FROM yourorg-docker.jfrog.io/yourorg/framework:latest
MAINTAINER you@yourorg.com
ADD https://yourorg.jfrog.io/yourorg/java-release-local/…/app-[RELEASE].war
/opt/jboss/wildfly/standalone/deployments/app.war

59. Application build Dockerfile
FROM yourorg-docker.jfrog.io/yourorg/framework:latest
MAINTAINER you@yourorg.com
ADD https://yourorg.jfrog.io/yourorg/java-release-local/…/app-[RELEASE].war
/opt/jboss/wildfly/standalone/deployments/app.war

60. Application build Dockerfile
FROM yourorg-docker.jfrog.io/yourorg/framework:latest
MAINTAINER you@yourorg.com
ADD https://yourorg.jfrog.io/yourorg/java-release-local/…/app-[RELEASE].war
/opt/jboss/wildfly/standalone/deployments/app.war

63. Framework Pipeline
Application Pipeline

64. Framework Pipeline
Application Pipeline

65. Framework Pipeline
Application Pipeline

68. HIGH QUALITY
(software and information) SPEED LOW COST
(automation)
Fast releases > Modular > Automation
Conclusions: Release Fast or
Die!