Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Virtual CD4PE Workshop

95 views

Published on

Learn how to use Continuous Delivery for Puppet Enterprise (CD4PE) in an interactive workshop with hands-on labs. What's CD4PE? CD4PE is the continuous delivery add-on to Puppet Enterprise, aimed at accelerating the speed at which you can get Puppet code changes deployed into production safely. CD4PE facilitates code collaboration across teams, and dramatically improves the release management process for teams that own & maintain individual Puppet modules. CD4PE integrates with both Puppet Enterprise as well as your version control system of choice.

After completing the workshop, you will be able to use CD4PE to perform common code management tasks on your Puppet control repo and modules.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Virtual CD4PE Workshop

  1. 1. Continuous Delivery for Puppet Enterprise Virtual Workshop 30 APRIL 2020
  2. 2. CD4PE WORKSHOP2 Continuous Delivery for Puppet Enterprise
  3. 3. Code -any code- is best managed with CI/CD CD4PE WORKSHOP3
  4. 4. Challenges of not having an automated workflow CD4PE WORKSHOP4
  5. 5. CD4PE: the most powerful add-on to Puppet Enterprise Everything you need when using Puppet at scale or across teams • Automates the validation & testing of Puppet code changes • For both control repos and modules • Manages & streamlines version control (git) workflows for you • Integrates natively with on-prem & cloud versions of Github, Gitlab, Bitbucket, Azure DevOps • Integrates with Puppet Enterprise for controlled deployments & approvals • Allows you to write custom deployments for bring-your-own-workflow • Enables multi-tenancy within or across Puppet Enterprise installations • Workspaces, protected environments requiring approval, fine-grained RBAC on modules • Delivery vehicle for future additional plugins CD4PE WORKSHOP5
  6. 6. Workshop setup CD4PE WORKSHOP6 <workshopID>-gitlab ● 1 Control Repo per student ● 1 Module Repo per student <workshopID>master0 <workshopID>cd4pe0 Teacher (me) <workshopID>master1 <workshopID>cd4pe1 Student 1 <workshopID>master2 <workshopID>cd4pe2 Student 2 <workshopID>master3 <workshopID>cd4pe3 Student 3
  7. 7. CD4PE WORKSHOP7 Lab 1: Installing CD4PE
  8. 8. Lab 1 - Logging in to Puppet Enterprise • Student machine pairs Puppet Enterprise: https://<workshopID>master<#>.classroom.puppet.com CD4PE host: http://<workshopID>cd4pe<#>.classroom.puppet.com:8080 (CD4PE is not yet installed!) • Example for workshop “wshop5” and student 3 Puppet Enterprise: https://wshop5master3.classroom.puppet.com CD4PE host: http://wshop5cd4pe3.classroom.puppet.com:8080 • Credentials Puppet Enterprise: admin / puppetlabs • Assign yourself a student nr via the Google Sheet that the instructor has shared CD4PE WORKSHOP8
  9. 9. Lab 1 - Installing CD4PE 1. Log in to your Enterprise Console (user: admin, password: puppetlabs) 2. Go to Classification, click Add Group… and create a PE Continuous Delivery group 3. Open the group and below Certname, select your <workshopID>cd4pe<#>.classroom.puppet.com node and click Pin node 4. Navigate to the Configuration tab and add the cd4pe class. 5. Below the added class click Parameter name, select cd4pe_version, change the value from “latest” to “3.x” and click Add parameter 6. On the bottom right, click Commit 2 changes and then run Puppet on the node by going to the Matching nodes tab, clicking the cd4pe node, then clicking the Run puppet… link at the top of the page and finally clicking the blue Run button. CD4PE WORKSHOP9
  10. 10. CD4PE WORKSHOP10 Discussion Q’s Why use a puppet module instead of the simple Bolt task? How can I upgrade to a newer minor version of CD4PE later?
  11. 11. CD4PE WORKSHOP11 Lab 2: CD4PE Setup Basics
  12. 12. Lab 2 - About setting up CD4PE Once the docker container is running, it's time to set up your CD4PE instance. Most of the configuration is done in CD4PE's graphical interface. The puppetlabs/cd4pe module has already setup the core software components and their connections for you: ● Docker Community Edition ● PE PostgreSQL (same as the database edition used by PE itself) ● CD4PE container image, with a docker volume (cd4pe-object-store) the rest of the configuration is up to you and done in the GUI. First we're going to configure the root account, which is responsible for overall management of the CD4PE instance. We will set up most of the basic settings here. Then we're going to create a user account, and a corresponding workspace. CD4PE WORKSHOP12
  13. 13. Lab 2 - Set up CD4PE root account 1. Browse to http://<workshopID>cd4pe<#>.classroom.puppet.com:8080 2. Click the friendly button to Get Started 3. You'll be asked to supply an email address and password for the root account 4. There is no email validation, so let’s all use root@classroom.puppet.com 5. Supply a password and write it down so you don’t lose it 6. Click to Create Root User CD4PE WORKSHOP13
  14. 14. Lab 2 - Set up CD4PE basic endpoints & storage 1. Now you'll be asked to configure endpoints, which are all on your CD4PE host with the default ports. Fill these in and save the settings: ● WebUI: http://<workshopID>cd4pe<#>.classroom.puppet.com:8080/ ● Backend Service: http://<workshopID>cd4pe<#>.classroom.puppet.com:8000/ ● Agent Service: dump://<workshopID>cd4pe<#>.classroom.puppet.com:7000/ 2. Next is configuring storage, used for things like the content of jobs. We'll use the default Disk option, which uses the docker volume, mapped to /disk in the container. Click Save Storage Settings. 3. You'll be asked for a license. Tell it to run in Trial Mode. 4. Scroll down the license agreement and click Accept without consulting an attorney. CD4PE WORKSHOP14
  15. 15. Lab 2 - Set up CD4PE user & workspace Okay, we're almost there. We can now create a normal user account and a workspace. A workspace is the area where a team integrates its own version control system, PE, control repository, and modules. This way several teams can share a CD4PE infrastructure, but only interact with their own resources. 1. Click to Create your user account 2. Fill in name, email, username, and password. As before, there is no email validation so it's safe to set it to something fun like kermit@classroom.puppet.com 3. Click the button, to Sign Up 4. Since this is a new install, you'll need to click to + Add New Workspace 5. Give it any name you like, for instance muppet-show and click Create workspace CD4PE WORKSHOP15
  16. 16. CD4PE WORKSHOP16 Discussion Q’s Why is there a separate root user and individual users? Why might I want to use multiple workspaces?
  17. 17. CD4PE WORKSHOP17 Lab 3: Integrate with PE
  18. 18. Lab 3 - About integrating with Puppet Enterprise CD4PE should use a service account when connecting to Puppet Enterprise. The account needs to be able to deploy code, make node groups, assign nodes to them, run tasks for jobs and run Puppet when a direct deployment policy is involved. In the interest of time, we've setup a cd4pe user with password puppetlabs in PE. This account already has all the necessary permissions. When you’re doing lab testing, you could also use the default admin account for a quick setup. In a real environment, you should use a restricted user account like we are doing in this workshop, with the minimal permissions as documented here. In this lab we will integrate CD4PE with Puppet Enterprise. We’ll also go back to the PE console, to make another change needed to enable full Impact Analysis. CD4PE WORKSHOP18
  19. 19. Lab 3 - Integrate with Puppet Enterprise 1. In your workspace, click the big Integrate Puppet Enterprise button up top 2. Click to Add Credentials, and name the instance puppet-enterprise 3. For the console address, simply supply puppet.classroom.puppet.com 4. Leave the radio box set to Basic Authorization 5. Supply the credentials for the admin account: cd4pe / puppetlabs 6. A token lifetime of 6 months is fine for the workshop, though you may prefer significantly longer in a real production environment 7. Click Save Changes 8. CD4PE will now link with Puppet Enterprise CD4PE WORKSHOP19
  20. 20. Lab 3 - Enabling full Impact Analysis (1/2) In order for CD4PE Impact Analysis to fully function, we need to make a small change to PE itself. Without this change, the impact of Hiera changes won’t be correctly detected. 1. Switch back to your Enterprise Console (user: admin, password: puppetlabs) 2. Go to Classification, click Add Group… and create a PE Impact Analysis group 3. Open the group and below Certname, select your puppet.classroom.puppet.com node and click Pin node 4. Navigate to the Configuration tab and add the cd4pe::impact_analysis class. 5. On the bottom right, click Commit 2 changes and then run Puppet on puppet.classroom.puppet.com (click the Matching nodes tab, click on the node called puppet.classroom.puppet.com, then click the Run puppet… link at the top of the page and finally click the blue Run button). CD4PE WORKSHOP20
  21. 21. Lab 3 - Enabling full Impact Analysis (2/2) 7. The run should take a minute. It will make 4 changes, you can optionally check the run report to verify. After this change, we need all the nodes to run Puppet at least once, so that the system can build a picture of all the Hiera data that each node uses. To do this: 8. Navigate to Puppet in the Run section of the left navigation bar. 9. In the Run Puppet screen, under Inventory, click Select a target type and choose Node group. Click on the Enter a node group box, and select All Nodes (production), then click Select. 10. Both our nodes should now show up. Click Run job on the bottom right hand side and wait for the run to complete. No changes should be reported. CD4PE WORKSHOP21
  22. 22. CD4PE WORKSHOP22 Discussion Q’s Why bother with a cd4pe service account in PE, instead of just using the admin account? Why is Hiera change analysis important?
  23. 23. CD4PE WORKSHOP23 Lab 4: Integrate with Gitlab
  24. 24. Lab 4 - About integrating with Gitlab CD4PE should use a service account when integrating with your source control server. In the interest of time, we've pre-created student accounts in the GitLab instance, that have access to all participants' repositories. So please make sure you pick your own control & module repositories! CD4PE WORKSHOP24
  25. 25. Lab 4 - Generate a Gitlab access token 1. Log in to https://<workshopID>-gitlab.classroom.puppet.com using the credentials student<#> (substitute <#> with your own number), and the password puppetlabs 2. Click the user icon ( ) in the upper-right corner to expose the drop-down menu, and click Settings 3. In the left-hand navigation, click Access Tokens 4. In the Name box, type something descriptive, like your name 5. In the Expires at box, set the expiration to anything beyond this week 6. Click the checkmarks for both api and read_user 7. Click the Create personal access token button 8. Copy the contents in the Your New Personal Access Token box at the top CD4PE WORKSHOP25
  26. 26. Lab 4 - Integrate with Gitlab 1. In CD4PE, click the Integrate source control button at the top of the screen 2. Click GitLab 3. Set the Host to https://<workshopID>gitlab0.classroom.puppet.com (NO dash!) 4. Paste the access token that you just generated from GitLab 5. Click Add Credentials 6. CD4PE will validate that the credentials work, generate an SSH keypair for itself and attach it to that user. You can check the SSH Keys section in Gitlab to verify. 7. After validation, you can click Done to dismiss the dialog. CD4PE WORKSHOP26
  27. 27. CD4PE WORKSHOP27 Discussion Q’s Why does CD4PE create an SSH key for itself in GitLab, if Code Manager is doing the deploys to Puppet Enterprise?
  28. 28. CD4PE WORKSHOP28 Lab 5: Adding Job Hardware
  29. 29. Lab 5 - About adding Job Hardware In order to run tests, CD4PE needs to have a pool of "job hardware" with the capabilities to run your tests. The built-in tests all run in Docker containers. You can make jobs that run in Docker, on Linux, on Windows, or even on MacOS, but all the built-ins are Docker. Since the CD4PE host already has docker on it -- running the CD4PE container -- it's simplest to re-use that hardware as job hardware. In production, use dedicated hosts as job hardware. A puppet profile can be used to make sure any pre-required software (like Docker) is installed on those hosts. CD4PE WORKSHOP29
  30. 30. Lab 5 - Add Job Hardware 1. In CD4PE, click the Set up job hardware button at the top of the screen 2. There is already 1 built-in capability: Docker. All we need to do is add a host to it. 3. Click the + Edit button to modify the hosts for the Docker capability 4. In the 2. Add hardware with this capability section, select the PE integration you added earlier in Lab 3 5. Click the checkbox next to your CD4PE server (<workshopID>cd4pe<#>) 6. Click the Save button, then click Done CD4PE WORKSHOP30
  31. 31. CD4PE WORKSHOP31 Discussion Q’s Why might you need Job hardware with a Windows capability? What risks might be associated with re-using the CD4PE host as job hardware?
  32. 32. CD4PE WORKSHOP32 Lab 6: Adding a Control Repo
  33. 33. Lab 6 - About adding a Control Repo Now that you've got all of your services integrated, it's time to aim CD4PE at your personal control repository. CD4PE is helpful enough to query GitLab using the service account we provided, and list all the repositories your account has access to. It's going to be a long list, so make sure you pick the one that's named with your participant number. Unlike with Code Manager, you don't have to add a webhook manually. CD4PE is going to do it for you when it adds the control repository in the GUI. CD4PE WORKSHOP33
  34. 34. Lab 6 - Add your Control Repo 1. Click the Add control repository button at the top of the screen 2. Click the Add Control Repo button and select GitLab in the list 3. Choose the puppet organization 4. Scroll to your control repo, named control-repo-<#> (again <#> is your own number) (Note: select the control repo, NOT the module repo) 5. Leave Branch set to master 6. Change the name of the control repo to: control-repo 7. Click Add CD4PE WORKSHOP34
  35. 35. CD4PE WORKSHOP35 Discussion Q’s Why might you want to integrate with more than one control repository?
  36. 36. CD4PE WORKSHOP36 Lab 7: Adding a default pipeline
  37. 37. Lab 7 - About adding a default pipeline Once you have a control repository configured for your workspace, you can add pipelines to automatically validate and deploy code in response to events in your VCS. (A webhook was automatically added for you, when you integrated the control repository into your workspace.) You will (over the course of several labs) add 2 pipelines to your control repository: 1. A master pipeline, which is triggered when either there is a push to the master branch, a pull request into your master branch, or a pull request is merged. 2. A regex pipeline, which is triggered when a certain branch name is created/updated. CD4PE manipulates branches that correspond to environments, much like you are used to doing already. Before it can manipulate them, they need to exist. We've already created these branches (development & production) for you, in the control & module repos. CD4PE WORKSHOP37
  38. 38. Lab 7 - Add a default pipeline for the master branch (1/2) 1. Click the + Add default pipeline button on the right hand side 2. On the bottom of the pipeline, click + Add a deployment 3. Under Select a node group, click Development environment 4. Under Select a deployment policy, click Direct deployment policy 5. Leave the defaults unchanged and click Add Deployment to Stage 6. Click + Add another stage after Deployment stage CD4PE WORKSHOP38
  39. 39. Lab 7 - Add a default pipeline for the master branch (2/2) 7. Under Stage name, enter Deploy to Production 8. We want to add a Deployment, which is the default item to add, so leave that as-is 9. Under Select a node group, click Production environment 10. Under Select a deployment policy, click Eventual consistency policy 11. Leave the defaults unchanged and click Add Stage, then click Done 12. Click the checkbox next to Auto promote between the Impact Analysis stage and the Deployment stage, so that this stage will automatically run after Impact Analysis. CD4PE WORKSHOP39
  40. 40. Lab 7 - Results Your pipeline should now look like the image on the right. Let’s also have a look at what the deployment policies do... CD4PE WORKSHOP40 Direct deployment & Eventual consistency: Temporary branch:
  41. 41. CD4PE WORKSHOP41 Discussion Q’s Why is it more likely to use Eventual Consistency deploys to production? Why would you typically not auto-promote to production?
  42. 42. CD4PE WORKSHOP42 Lab 8: Running the pipeline
  43. 43. Lab 8 - About running the pipeline We now have a basic pipeline ready to go, let’s make a simple change in our control repo and see what happens in CD4PE when the change is committed. What we expect to happen: 1. All code in the control repo is validated to ensure there are no syntax errors 2. An Impact Analysis is performed of both the Development and Production environments (we can change this to just one environment for increased speed) 3. The change is deployed to the Development environment 4. Nothing happens yet in production, but we can manually promote the change to the Production environment. Note: we set the PE Master in the production environment, CD4PE is in development. CD4PE WORKSHOP43
  44. 44. Lab 8 - Commit a change to your Control Repo 1. Navigate to https://<workshopID>-gitlab.classroom.puppet.com 2. Find and click on your own Control Repo in the list (puppet/control-repo-<#>) 3. Navigate to /site-modules/profile/manifests and review the contents of common.pp 4. Navigate to /data, click on common.yaml, then click the Edit button on the right 5. For the nano package on line 4, change: ensure: absent → ensure: present 6. Optional: change the Commit message to something witty but informative 7. Click Commit changes 8. Switch back to CD4PE and notice a New Events message appearing CD4PE WORKSHOP44
  45. 45. Lab 8 - Reviewing the pipeline run (1/2) 1. Back in CD4PE, click the New Events notification icon. If you don’t see this icon, that’s possible due to AWS load balancer timeouts. In that case, simply refresh the page. 2. The first stage that runs is the Code Validation stage. This contains 4 built-in jobs that check code, hiera, puppetfile and template syntax for everything in your control repo. 3. Click on their job numbers (#1, #2, etc.) to view their output 4. The second stage is the Impact Analysis stage. This stage determines what will happen when our updated code is deployed to the development and production environments. Click it’s number (#1) to view the information. 5. Click on View changes next to the development environment results to see the impact of our code change. CD4PE WORKSHOP45
  46. 46. Lab 8 - Reviewing the pipeline run (2/2) 6. Notice that for the production environment there was no impact? Take a look at /data/nodes/puppet.classroom.puppet.com.yaml in Gitlab to see why… 7. The third stage of the pipeline is the deployment to the Development environment. Click on it’s number (#2) to see the details. 8. The deployment actually is a Bolt Plan under the hood. The output we’re seeing are Bolt Tasks that are performed by the Plan. You can even write custom deployment policies to create your own deployment strategy! 9. Because we used a Direct deployment policy here, the change has been immediately enforced. Open the details of this deployment and click View jobs on the Orchestration task to see the results. Then check in PE, on the Jobs page, that Puppet has indeed ran on the CD4PE host to install the nano package. CD4PE WORKSHOP46
  47. 47. CD4PE WORKSHOP47 Discussion Q’s What would be the use case for a custom deployment policy?
  48. 48. CD4PE WORKSHOP48 Lab 9: Promoting to production
  49. 49. Lab 9 - Commit another change to your Control Repo 1. Navigate to https://<workshopID>-gitlab.classroom.puppet.com 2. Find and click on your own Control Repo in the list (puppet/control-repo-<#>) 3. Navigate to /data/nodes, click on puppet.classroom.puppet.com.yaml, then click the Edit button on the right 4. For the nano package on line 4, change: ensure: absent → ensure: present 5. Optional: change the Commit message to something witty but informative 6. Click Commit changes 7. Switch back to CD4PE and notice a New Events message appearing CD4PE WORKSHOP49
  50. 50. Lab 9 - Review the pipeline and promote to production 1. Back in CD4PE, click the New Events notification button. If you don’t see it, that’s possible due to AWS load balancer timeouts. In that case, simply refresh the page. 2. Open the details for the Impact Analysis stage and wait for it to run. Once complete, notice the impact for both environments: ○ the development environment will show no changes this time (no impact) ○ the production environment now also shows changes, due to our latest file change 3. Once the pipeline has completed, click the button between the Deployment stage and the Deploy to Production stage, and click Promote, then Done. 4. Click the New Events button and view the details of the deployment. Notice this deployment is only updating the code in PE, and is not immediately running Puppet. 5. Optional: run Puppet on the PE Master and verify it makes the change. CD4PE WORKSHOP50
  51. 51. CD4PE WORKSHOP51 Discussion Q’s Why does CD4PE only show the last commit in the code promotion screen?
  52. 52. CD4PE WORKSHOP52 Lab 10: Adding a regex pipeline
  53. 53. Lab 10 - About regex pipelines CD4PE prescribes a feature-branch development style. On the surface -- and it's okay to stop at the surface if you need -- it's a lot like the git flow we've all been doing forever. Branch off master into a feature branch to try out something. Merge into master, then development, then production. Repeat. A regex pipeline automates the part of the flow where you create a feature branch and push it up to try things. Just like in the git-flow-with-code-manager style, you push a feature branch and it creates an environment named the same. But with the addition of pipelines, you can now do things like have all feature branch pushes automatically run code validation before deploying to the feature-branch environment on the master. CD4PE WORKSHOP53
  54. 54. Lab 10 - Create a regex pipeline 1. In CD4PE, go back to your control repo pipeline 2. Over on the right is a drop down box that says master -- click the to the right of it 3. Click the radio button to switch to Branch regex 4. Leave the default regex as feature_.* and click Add Pipeline, then Done 5. For your new pipeline, click + Add default pipeline 6. Find the Pull Request Gate, and click X to delete it (no PR’s used in a feature branch) 7. Click Add a deployment and select the Feature branch policy 8. Accept the defaults and click Add Deployment to Stage, then Done CD4PE WORKSHOP54
  55. 55. Lab 10 - Create a feature branch and run the pipeline (1/3) 1. Switch over to your control repo in Gitlab 2. On the left hand navigation bar, go to Branches (in the Repository section) 3. Click the green New Branch button on the top right 4. Type in feature_emacs for the Branch name, and leave Create from to master 5. Notice that in CD4PE, a feature branch pipeline has kicked off. 6. Once the pipeline finishes, switch over to Puppet Enterprise and update the classes (Classification → All Environments → Configuration tab → Refresh link on the right) 7. On the right, click Edit node group metadata. Notice the feature_emacs environment now shows in the Environment dropdown box. Click Discard metadata changes. CD4PE WORKSHOP55
  56. 56. Lab 10 - Create a feature branch and run the pipeline (2/3) We now have our shiny new branch in Puppet, but it doesn’t have any changes yet…. 8. Switch back to Gitlab, and while in the feature_emacs branch, navigate to /data, click on common.yaml, then click the Edit button on the right 9. After line 6, add 2 new lines for a emacs package (use the same indentation!): emacs: ensure: present 10. Optional: change the Commit message to something witty but informative 11. Click Commit changes 12. Switch back to CD4PE, and see the pipeline trigger again CD4PE WORKSHOP56
  57. 57. Lab 10 - Create a feature branch and run the pipeline (3/3) 13. Once the pipeline finishes, switch over to Puppet Enterprise 14. Our changed code is now available in the feature_emacs environment, but no nodes are classified to that particular environment. However, rather changing the classification permanently, we can also run Puppet once with an environment override. Navigate to Puppet in the Run section of the left navigation bar. 15. In the Run Puppet screen, under Environment, set the radio button to Select an environment for nodes to run in and select the feature_emacs environment. 16. Click Select a target type below Inventory and choose Node list. Type cd4pe and click Search. Select your CD4PE node and click Run job on the bottom right hand side. 17. Notice there is 1 intentional change. Check the report to verify emacs was installed CD4PE WORKSHOP57
  58. 58. CD4PE WORKSHOP58 Discussion Q’s Why require that feature branches have names matching a regular expression?
  59. 59. CD4PE WORKSHOP59 Lab 11: Using Pull Requests
  60. 60. Lab 11 - About pull requests Finally, we're getting ready to complete the development cycle by creating a pull request to propose our feature branch changes into the master branch. Once validated in the CD4PE pipeline, and the Impact Analysis review, we can decide to approve it and merge the changes. First we need to enable our CD4PE to trigger on Pull Requests, after that we can create the PR and go through the workflow. CD4PE WORKSHOP60
  61. 61. Lab 11 - Enable Pull Request triggers on the pipeline 1. Switch back to CD4PE and go back to your control repo pipeline 2. Over on the right, below Pipelines, click the dropdown box (it probably still says regex) and change it back to master. Then click Manage pipelines on the top right. 3. In the Triggers section, put a checkbox next to PullRequest 4. Click Save Settings, then Done 5. Notice that below the pipeline dropdown box that says master, the Pipeline trigger status now says Commit, Pull request. CD4PE WORKSHOP61
  62. 62. Lab 11 - Create a Pull Request that triggers the pipeline (1/2) 1. Switch to Gitlab and click Merge Requests on the left hand navigation bar. 2. Click the green New merge request button 3. Click the Select source branch dropdown box and select feature_emacs 4. Ensure the target branch is set to master (it’s the default) and click Compare branches and continue. 5. Notice Gitlab tries to automatically name your PR for you, based on the commits made. Put a checkbox next to Remove source branch when merge request is accepted, so we don’t have to cleanup manually afterwards. 6. Click the green Submit merge request button near the bottom. Leave this page as-is. CD4PE WORKSHOP62
  63. 63. Lab 11 - Create a Pull Request that triggers the pipeline (2/2) 7. Switch to CD4PE and click the New Events notification to see the new pipeline. Notice that this time, the pipeline only runs until the Impact Analysis. The Pull Request Gate after Impact Analysis has prevented the pipeline from running further for pending PR’s. 8. View the details of the Impact Analysis. Verify there is no impact as our CD4PE node has already been updated in the previous lab, and the change doesn’t affect the PE master as it has its own Hiera data that overrules the default from common.yaml. 9. Switch back to Gitlab, where we can see the pipeline status has synced back to the PR. Now that we’re happy with the expected impact, click the Merge button to approve the Pull Request. 10. Switch back to CD4PE and monitor the pipeline as it re-runs the pipeline, now all the way to deploying the changes to the development environment. CD4PE WORKSHOP63
  64. 64. CD4PE WORKSHOP64 Discussion Q’s Why did the pipeline stop after Impact Analysis for the Pull Request, but not the merge?
  65. 65. CD4PE WORKSHOP65 Lab 12: Adding a module
  66. 66. Lab 12 - About adding modules If you keep your modules in their own individual repositories, you can have CD4PE manage their deployment. Just like the control repository, they will have pipelines to validate code, run Impact Analysis, and deploy to environments. Pushing a feature branch even causes CD4PE to make a corresponding branch in the control repository and deploy it, saving you a few manual steps. In this lab, the module we’re adding contains a new task that has only been saved in the master branch; it hasn’t been promoted to other environments yet. We will use CD4PE to manually trigger a workflow on this commit and see the task appear in CD4PE. CD4PE WORKSHOP66
  67. 67. Lab 12 - Add your module 1. In CD4PE, in the left-hand navigation, select Modules 2. Over on the right, click Add Module 3. Choose GitLab as the source 4. Choose the puppet organization 5. Select your numbered puppet-mymodule-<#> repository 6. Click Add 7. It should detect a .cd4pe.yaml file in this repo. Click Yes, manage as code 8. Click Done to dismiss the dialog. CD4PE WORKSHOP67
  68. 68. Lab 12 - Trigger the module pipeline 1. In CD4PE, on the right-hand top, click Manual actions → Trigger Pipeline 2. Select the master pipeline 3. Select the commit named add task mymodule::puppetdb_query 4. Click Trigger Pipeline, then Done 5. Click the New Events notification to view the pipeline. Wait until it completes. 6. Switch back to Puppet Enterprise and navigate to Run → Task 7. Under Code environment, select development and then search for the mymodule::puppetdb_query task in the Task box 8. Set the factname parameter to ipaddress and then run the task on the PE Master CD4PE WORKSHOP68
  69. 69. CD4PE WORKSHOP69 Discussion Q’s Suppose several teams have to cooperate on a single "profile", but they have to promote their changes at different velocities. How might breaking out profiles into team-specific modules make this manageable?
  70. 70. CD4PE WORKSHOP70 Lab 13: Protecting an environment group
  71. 71. Lab 13 - About protected environment groups You can mark environments as protected in CD4PE, and specify groups of users who are allowed to approve deployments to those environments. This is similar to how you used to protect branches in your VCS, in order to keep them from being inappropriately deployed. But with CD4PE, you let it do the protection. You can even use the combination of both protected environment groups in CD4PE, and protected branches in your VCS, for ultimate security of your code changes. CD4PE WORKSHOP71
  72. 72. Lab 13 - Create an approval group First, you need to make a group of approvers, and add yourself to it. 1. In CD4PE, in the left-hand navigation, select Settings → Groups → Create new group 2. Enter Approvers as the group name and click Save 3. Under Control Repos, click the checkbox next to the List option. 4. Under Modules, click the checkbox next to the List option. 5. Click Save and add users, and tick the box next to your username 6. Click Add users to group, then Done CD4PE WORKSHOP72
  73. 73. Lab 13 - Protect a PE environment group 1. In CD4PE, in the left-hand navigation, select Settings → Puppet Enterprise 2. In the column for Protected Environments click on the number 0, then click Add 3. Select the production environment 4. To enable the Approvers group, click on its slider 5. Click Add, then Done 6. Click Done to dismiss the dialog. CD4PE WORKSHOP73
  74. 74. Lab 13 - Trigger a deployment to production 1. In CD4PE, navigate back to your control repo pipeline 2. Click the button between the Deployment stage and the Deploy to Production stage, and click Promote, then Done. 3. Click the New Events button and view the details of the deployment. 4. Notice the deployment to production is now in a Pending Approval state. 5. Since you are an Approver, go ahead and open the details of the deployment and Approve the deployment. 6. A few seconds after approving, the rest of the deployment policy will kick in. CD4PE WORKSHOP74
  75. 75. CD4PE WORKSHOP75 Discussion Q’s What if some malicious person just pushes code to the production branch, "bypassing" CD4PE's approval?
  76. 76. CD4PE WORKSHOP76 You made it! Well done!
  77. 77. Thank you.

×