RPM packaging provides advantages for software deployment including being an open standard format that is well integrated with many environments. The document discusses how RPM builds work and examples of RPM packaging pipelines. It also explains how RPMs can be used effectively within Docker containers and environments, providing cleaner Dockerfiles and images while allowing software to be deployed both with or without Docker.

1. RPM Packaging
How software delivery works and why RPM packaging is more current than ever
Fabio Alessandro Locati
26 October 2016

2. Outline
Intro
Deployments
RPM Processes
RPM and Docker
1

3. Intro

4. About me
2

5. About me
• RPM user since 2001
2

6. About me
• RPM user since 2001
• IT Consultant since 2004
2

7. About me
• RPM user since 2001
• IT Consultant since 2004
• RPMs creator since 2013
2

8. Deployment in the past
3

9. Deployment in the past
• Mayority of application needed to be deployed on a single system
3

10. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
3

11. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
3

12. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
• Devs ready to patch
3

13. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
• Devs ready to patch
• Ops ready to deploy work-around
3

14. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
• Devs ready to patch
• Ops ready to deploy work-around
• Usually performed during night-time
3

15. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
• Devs ready to patch
• Ops ready to deploy work-around
• Usually performed during night-time
• Hours of downtime
3

16. Deployment in the past
• Mayority of application needed to be deployed on a single system
• Annual/Bi-annual
• All hands on deck
• Devs ready to patch
• Ops ready to deploy work-around
• Usually performed during night-time
• Hours of downtime
• Very expensive deployments
3

17. Today expectations
4

18. Today expectations
• Deploy multiple times every day
4

19. Today expectations
• Deploy multiple times every day
• Cheap deployments
4

20. Today expectations
• Deploy multiple times every day
• Cheap deployments
• No down time
4

21. Today expectations
• Deploy multiple times every day
• Cheap deployments
• No down time
• Need of mass deployment (tens/hundreds/thousands of systems)
4

22. Today expectations
• Deploy multiple times every day
• Cheap deployments
• No down time
• Need of mass deployment (tens/hundreds/thousands of systems)
• Horizontal (dynamic) scalability
4

23. Deployments

24. Items that could be involved in deployments
5

25. Items that could be involved in deployments
• Code
5

26. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
5

27. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
5

28. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
• Software packaging system: RPM, DEB, Docker, WAR, generic archive
5

29. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
• Software packaging system: RPM, DEB, Docker, WAR, generic archive
• Test system: Bodhi, Jenkins
5

30. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
• Software packaging system: RPM, DEB, Docker, WAR, generic archive
• Test system: Bodhi, Jenkins
• Environment packaging system: Docker, PyEnv
5

31. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
• Software packaging system: RPM, DEB, Docker, WAR, generic archive
• Test system: Bodhi, Jenkins
• Environment packaging system: Docker, PyEnv
• Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
5

32. Items that could be involved in deployments
• Code
• Source Control System (SCM): git, hg, svn, cvs
• Build system: Koji, Jenkins, Shell
• Software packaging system: RPM, DEB, Docker, WAR, generic archive
• Test system: Bodhi, Jenkins
• Environment packaging system: Docker, PyEnv
• Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
• Execution environment: Native OS, OpenStack, OpenShift, Docker, runc
5

33. RPM as software packaging system
6

34. RPM as software packaging system
• Advantages
6

35. RPM as software packaging system
• Advantages
• Very well known format
6

36. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
6

37. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
6

38. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
6

39. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
6

40. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
• Checksum of all files
6

41. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
• Checksum of all files
• Very rigid policies
6

42. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
• Checksum of all files
• Very rigid policies
• Disadvantages
6

43. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
• Checksum of all files
• Very rigid policies
• Disadvantages
• Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,
CentOS, SL)
6

44. RPM as software packaging system
• Advantages
• Very well known format
• Open Standard
• Clear distinction between compile environment and run environment
• Easy to integrate with any kind of environment
• Very good at resolving dependencies
• Checksum of all files
• Very rigid policies
• Disadvantages
• Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,
CentOS, SL)
• Very rigid policies
6

45. RPM components
7

46. RPM components
• SPEC file
7

47. RPM components
• SPEC file
• Sources files (at least 1)
7

48. RPM components
• SPEC file
• Sources files (at least 1)
• Patches (eventually)
7

49. RPM Processes

50. RPM build process
8

51. RPM build process
• Fetch of the SPEC file
8

52. RPM build process
• Fetch of the SPEC file
• Fetch of sources/patches
8

53. RPM build process
• Fetch of the SPEC file
• Fetch of sources/patches
• Creation of the .src.rpm file
8

54. RPM build process
• Fetch of the SPEC file
• Fetch of sources/patches
• Creation of the .src.rpm file
• Creation of binaries .rpm files
8

55. Fedora pipeline
9

56. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
9

57. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
9

58. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
• Build in Koji
9

59. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
• Build in Koji
• Promotion to Bodhi testing branch
9

60. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
9

61. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
• Manual testing
9

62. Fedora pipeline
• SPEC file, additional sources, and patches in git repo
• Upstream source in cache system
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
• Manual testing
• Promotion to Bodhi stable branch
9

63. Example RPM pipeline 1
10

64. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
10

65. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
10

66. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Promotion to Bodhi testing branch
10

67. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
10

68. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
• Manual testing
10

69. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
• Manual testing
• Promotion to Bodhi stable branch
10

70. Example RPM pipeline 1
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Promotion to Bodhi testing branch
• Automated tests by Bodhi and AutoQA
• Manual testing
• Promotion to Bodhi stable branch
• Simple upgrade of live system (yum update -y PACKAGE)
10

71. Example RPM pipeline 2
11

72. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
11

73. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
• Build in Koji
11

74. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Creation of a Docker image
11

75. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Creation of a Docker image
• Automated tests
11

76. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Creation of a Docker image
• Automated tests
• Manual testing
11

77. Example RPM pipeline 2
• SPEC file, additional sources, and patches in git repo
• Build in Koji
• Creation of a Docker image
• Automated tests
• Manual testing
• Propagate the new Docker image
11

78. RPM and Docker

79. RPM and Docker
12

80. RPM and Docker
• RPM work very well in Docker environments
12

81. RPM and Docker
• RPM work very well in Docker environments
• Installing RPMs allow a cleaner Docker file and image
12

82. RPM and Docker
• RPM work very well in Docker environments
• Installing RPMs allow a cleaner Docker file and image
• RPMs can be deployed within or without Docker
12

83. Docker example
RUN dnf install -y tar make gcc ruby ruby-devel rubygems graphviz
rubygem-nokogiri unzip findutils which wget python-devel
zlib-devel libjpeg-devel redhat-rpm-config patch
&& dnf clean packages
&& gem install --no-ri --no-rdoc asciidoctor --version
$ASCIIDOCTOR_VERSION
&& gem install --no-ri --no-rdoc asciidoctor-pdf --version
1.5.0.alpha.11
&& gem install --no-ri --no-rdoc slim
&& (curl -LkSs https://api.github.com/repos/asciidoctor
| tar xfz - -C $BACKENDS --strip-components=1)
&& wget https://bitbucket.org/pypa/setuptools/raw/bootstrap
-O - | python 13

84. Docker example with RPM
RUN dnf install -y rubygem-asciidoctor-pdf
&& dnf clean packages
14

85. Size of the images
• Fedora base image: 204MB
15

86. Size of the images
• Fedora base image: 204MB
• First image: 776MB
15

87. Size of the images
• Fedora base image: 204MB
• First image: 776MB
• Second image: 238MB
15

88. Additional resources
• Laboratorio ICT, 14:00 - Come pacchettizzare applicazioni in formato RPM
• Slides: https://slides.fale.io/20161026-en-rpm.pdf
• Official website: http://rpm.org
• Fedora guide: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
• RPM Guide: http://rpm-guide.readthedocs.io
16