%20Logo%20500x500%20px%20-%20Custom%20dimensions.png)
Jenkins-Day-2
### Project Scenario: Configuring Jenkins with Role-Based Authorization with Global Roles and Validating with a Sample Job
Objective: Set up Jenkins for a software development team, implementing a role-based authorization strategy with global roles. This project will include installing necessary plugins, defining roles, creating users, setting up a sample project and job, and validating the roles with the job.
### Step 1: Install Required Plugins
Scenario: To manage permissions effectively through roles, the "Role-Based Authorization Strategy" plugin must be installed.
1. Access Jenkins Dashboard:
- Log in to Jenkins as an administrator.
2. Navigate to Plugin Manager:
- Go to `Manage Jenkins` > `Manage Plugins`.
3. Install "Role-Based Authorization Strategy" Plugin:
- Click on the `Available` tab.
- Search for `Role-Based Authorization Strategy`.
- Check the box next to the plugin and click `Install without restart`.
- Wait for the installation to complete.
### Step 2: Configure Role-Based Authorization Strategy with Global Roles
Scenario: Define global roles for different levels of access within Jenkins: `Admin`, `Developer`, and `Viewer`.
1. Enable Role-Based Authorization:
- Go to `Manage Jenkins` > `Security`.
- In the `Authorization` section, select `Role-Based Strategy`.
- Click `Save` to apply the changes.
2. Define Global Roles:
- Go to `Manage Jenkins` > `Manage and Assign Roles` > `Manage Roles`.
- In the `Global roles` section, create the following roles:
- Admin: Full access to all Jenkins features, including system settings and job management. Check all permissions.
- Developer: Permissions to create, modify, and run jobs but no access to system settings. Check permissions such as `Job Create`, `Job Configure`, `Job Delete`, `Job Build`, etc.
- Viewer: Read-only access, allowing users to view job statuses and build results. Check permissions like `Job Read`, `Overall Read`.
### Step 3: Create Users and Assign Global Roles
Scenario: Assign specific users to the roles created based on their responsibilities within the team.
1. Create Users:
- Go to `Manage Jenkins` > `Manage Users`.
- Create the following users:
- admin_user: Administrator with full control.
- dev_user1 and dev_user2: Developers who will manage and run jobs.
- viewer_user: A user with read-only access.
2. Assign Roles to Users:
- Go to `Manage Jenkins` > `Manage and Assign Roles` > `Assign Roles`.
- In the `Global roles` section, assign users to their respective roles:
- admin_user: Assign to the `Admin` role.
- dev_user1 and dev_user2: Assign to the `Developer` role.
- viewer_user: Assign to the `Viewer` role.
### Step 4: Create a Sample Project and Job
Scenario: Create a sample project with a basic job to validate the roles. The job will be a simple Jenkins pipeline that prints "Hello, Jenkins!"
1. Create a New Project:
- Go to the Jenkins dashboard.
- Click `New Item` and name it `Sample_Project`.
- Choose `Freestyle project` and click `OK`.
2. Configure the Job:
- In the `Build` section, click `Add build step`.
- Select `Execute shell`.
- In the command box, enter:
echo "Hello, Jenkins!"
3. Run the Job:
- From the project dashboard, click `Build Now` to run the job.
### Step 5: Validation
Scenario: Validate that the roles and permissions are set correctly by testing with each user account.
1. Validate Admin Role:
- Log in as `admin_user`.
- Confirm that this user can access and modify all Jenkins settings, including creating, configuring, and running jobs.
2. Validate Developer Role:
- Log in as `dev_user1`.
- Ensure that this user can create, configure, and run jobs in `Sample_Project` but cannot modify global Jenkins settings.
3. Validate Viewer Role:
- Log in as `viewer_user`.
- Confirm that this user can only view the job and its build results in `Sample_Project` without the ability to make any changes.
### Conclusion
This project scenario ensures that Jenkins is set up with a role-based authorization strategy tailored to the needs of your software development team. By following these steps, you can effectively manage permissions and validate the setup using a sample job, ensuring a secure and well-organized Jenkins environment.
### Project Scenario: Creating and Assigning Item Roles in Jenkins with a Validation Job
Objective: Set up Jenkins with item roles to manage access to specific projects and jobs. The process includes creating users, defining and assigning item roles, setting up a sample project and job, and validating the roles with the job.
### Step 1: Set Up Jenkins and Enable Role-Based Authorization
Scenario: To control access to specific projects and jobs within Jenkins, you’ll implement item roles as part of the role-based authorization strategy.
1. Access Jenkins Dashboard:
- Log in to Jenkins as an administrator.
2. Navigate to Security Configuration:
- Go to `Manage Jenkins` > `Security`.
3. Enable Role-Based Authorization:
- In the `Authorization` section, select `Role-Based Strategy`.
- Click `Save` to apply the changes.
### Step 2: Create Users
Scenario: Create users who will be assigned different item roles based on their responsibilities.
1. Create Users:
- Go to `Manage Jenkins` > `Manage Users`.
- Create the following users:
- pm_user: A project manager responsible for managing specific projects.
- dev_user1 and dev_user2: Developers responsible for working on specific projects.
### Step 3: Install the Role-Based Authorization Strategy Plugin (If Not Already Installed)
Scenario: Ensure that the "Role-Based Authorization Strategy" plugin is installed to manage item roles.
1. Navigate to Plugin Manager:
- Go to `Manage Jenkins` > `Manage Plugins`.
2. Install "Role-Based Authorization Strategy" Plugin:
- Click on the `Available` tab.
- Search for `Role-Based Authorization Strategy`.
- Check the box next to the plugin and click `Install without restart`.
- Wait for the installation to complete.
### Step 4: Create and Define Item Roles
Scenario: Define item roles to control access to specific jobs or projects within Jenkins.
1. Navigate to Role Management:
- Go to `Manage Jenkins` > `Manage and Assign Roles` > `Manage Roles`.
2. Create Item Roles:
- In the `Item roles` section, define roles such as:
- Project_Manager: Full permissions to configure, build, and delete specific projects.
- Developer: Permissions to build and configure jobs but not delete them.
3. Assign Patterns to Item Roles:
- Define the scope of each role using patterns:
- Assign the `Project_Manager` role with the pattern `Project_*` to give `pm_user` control over items prefixed with `Project_`.
- Assign the `Developer` role with the pattern `Project_*` to give `dev_user1` and `dev_user2` restricted control (build and configure) over the same items.
### Step 5: Create a Sample Project and Job
Scenario: Create a sample project with a job to validate the item roles.
1. Create a New Project:
- Go to the Jenkins dashboard.
- Click `New Item` and name it `Project_Sample`.
- Choose `Freestyle project` and click `OK`.
2. Configure the Job:
- In the `Build` section, click `Add build step`.
- Select `Execute shell`.
- In the command box, enter:
echo "Building Project_Sample"
- Click `Save`.
3. Run the Job:
- From the project dashboard, click `Build Now` to run the job.
### Step 6: Assign Users to Item Roles
Scenario: Assign specific users to the item roles based on their responsibilities.
1. Assign Roles to Users:
- Go to `Manage Jenkins` > `Manage and Assign Roles` > `Assign Roles`.
- In the `Item roles` section, assign users to their respective roles:
- pm_user: Assign to the `Project_Manager` role for `Project_*` items.
- dev_user1 and dev_user2: Assign to the `Developer` role for `Project_*` items.
### Step 7: Validation
Scenario: Validate the setup by testing access and permissions for each user account.
1. Validate Project Manager Role:
- Log in as `pm_user`.
- Confirm that this user can configure, build, and delete the `Project_Sample` job.
2. Validate Developer Role:
- Log in as `dev_user1`.
- Ensure that this user can configure and build the `Project_Sample` job but cannot delete it.
### Conclusion
This project scenario ensures that Jenkins is set up with item roles tailored to the needs of your team. By following these steps, you can effectively manage permissions and validate the setup using a sample job, ensuring a secure and well-organized Jenkins environment.
### Project Scenario: Configuring Jenkins with Project-Based Matrix Authorization Strategy and Build Triggers
Objective: Set up Jenkins using a project-based matrix authorization strategy. This includes creating users, defining permissions at the project level, setting up a sample project with a job, and configuring the job to build periodically using build triggers.
### Step 1: Set Up Jenkins and Enable Project-Based Matrix Authorization Strategy
Scenario: You want to manage access to specific projects and jobs within Jenkins at a more granular level using a project-based matrix authorization strategy.
1. Access Jenkins Dashboard:
- Log in to Jenkins as an administrator.
2. Navigate to Security Configuration:
- Go to `Manage Jenkins` > `Configure Global Security`.
3. Enable Project-Based Matrix Authorization Strategy:
- In the `Authorization` section, select `Project-based Matrix Authorization Strategy`.
- Click `Save` to apply the changes.
### Step 2: Create Users
Scenario: Create users who will be assigned different permissions on specific projects.
1. Create Users:
- Go to `Manage Jenkins` > `Manage Users`.
- Create the following users:
- admin_user: Administrator with full control over all projects and settings.
- pm_user: Project Manager with control over specific projects.
- dev_user1 and dev_user2: Developers with limited permissions to work on specific projects.
### Step 3: Create a New Project
Scenario: Create a sample project in Jenkins where different users will have different levels of access.
1. Create a New Project:
- Go to the Jenkins dashboard.
- Click `New Item`, name it `Sample_Project`, and select `Freestyle project`.
- Click `OK`.
2. Configure Project-Based Matrix Authorization for the Project:
- Within the project configuration page, scroll down to the `Build Triggers` section.
- Check the box for `Enable project-based security`.
- Configure the matrix permissions for this project:
- admin_user: Assign all permissions (check all boxes).
- pm_user: Assign permissions for configuring the project, running builds, and viewing build results (`Job Configure`, `Job Build`, `Job Read`).
- dev_user1 and dev_user2: Assign permissions for building the project and viewing build results (`Job Build`, `Job Read`).
3. Save the Configuration:
- Click `Save` to apply the configuration.
### Step 4: Configure a Sample Job with Build Triggers
Scenario: Set up a job within the `Sample_Project` that will build periodically based on a schedule.
1. Configure the Job:
- In the `Build Triggers` section of the project configuration, check the box for `Build periodically`.
- Enter a cron expression to schedule the build. For example, to build every 2 minutes :
H */2 * * * *
- Add a build step by clicking `Add build step` and selecting `Execute shell`.
- In the command box, enter:
echo "Building Sample_Project"
2. Save and Trigger the Job:
- Click `Save` to apply the configuration.
- The job will now run automatically based on the defined schedule.
### Step 5: Validation
Scenario: Validate that the users have the correct permissions and that the job builds according to the schedule.
1. Validate Admin Role:
- Log in as `admin_user`.
- Confirm full access to configure, build, and delete the `Sample_Project`.
2. Validate Project Manager Role:
- Log in as `pm_user`.
- Ensure this user can configure and build the `Sample_Project`, but cannot delete it.
3. Validate Developer Roles:
- Log in as `dev_user1`.
- Ensure this user can only build and view the results of the `Sample_Project`.
4. Check Build Triggers:
- Wait for the scheduled time or manually trigger the build to ensure it runs as configured.
### Conclusion
This project scenario provides a structured approach to setting up Jenkins with a project-based matrix authorization strategy. By following these steps, you can manage permissions at a granular level, ensuring that each user has the appropriate access. The job's periodic build configuration helps automate the build process, ensuring continuous integration without manual intervention.
### Project Scenario: Configuring Jenkins with Poll SCM Build Triggers
Objective: Set up a Jenkins project that automatically checks for changes in a source code repository using Poll SCM and triggers builds when changes are detected. This scenario includes creating the project, configuring jobs, and setting up Poll SCM build triggers.
### Step 1: Set Up Jenkins Project
Scenario: Create a new project in Jenkins that will include a job with a Poll SCM trigger.
1. Access Jenkins Dashboard:
- Log in to Jenkins as an administrator.
2. Create a New Project:
- From the Jenkins dashboard, click `New Item`.
- Enter the project name as `Poll_SCM_Project`.
- Select `Freestyle project` and click `OK`.
### Step 2: Configure Source Code Management (SCM)
Scenario: Configure the project to pull code from a source code management (SCM) repository.
1. Configure SCM:
- On the project configuration page, scroll down to the `Source Code Management` section.
- Select the appropriate SCM system (e.g., `Git`).
- Enter the repository URL (e.g., `https://github.com/your-repo/sample-project.git`).
- Add credentials if necessary for accessing the repository.
- Specify the branch to build (e.g., `*/main`).
### Step 3: Set Up Poll SCM Build Trigger
Scenario: Configure Jenkins to automatically poll the SCM repository for changes and trigger builds when changes are detected.
1. Configure Poll SCM Trigger:
- Scroll down to the `Build Triggers` section.
- Check the `Poll SCM` option.
- Enter a cron expression to define the polling schedule. For example, to poll every 5 minutes:
*/5 * * * *
- This means Jenkins will check the repository every 5 minutes and trigger a build if there are changes.
### Step 4: Add a Build Step
Scenario: Set up a simple build step to validate the build process.
1. Configure the Build Step:
- In the `Build` section, click `Add build step` and select `Execute shell`.
- In the command box, enter:
echo "Building Poll_SCM_Project"
- This is a placeholder command that simply prints a message during the build.
### Step 5: Save and Build
Scenario: Save the project configuration and ensure that the job builds when changes are detected in the SCM.
1. Save the Configuration:
- Scroll down and click `Save` to apply the project configuration.
2. Trigger a Manual Build (Optional):
- To test the setup, you can manually trigger a build by clicking `Build Now` from the project dashboard.
### Step 6: Validate Poll SCM Trigger
Scenario: Ensure that the Poll SCM trigger works as expected.
#### Scenario
In this project, you'll create a new GitHub repository, clone it to an EC2 instance, create a file locally, and push the file to the remote repository on GitHub. This scenario simulates a typical workflow for managing code using Git and GitHub on a cloud server.
#### 1. Create a GitHub Repository
- Go to GitHub: Log in to your GitHub account.
- Create a New Repository:
- Click on the "New" button to create a new repository.
- Enter a repository name, for example, `ec2-git-demo`.
- You can add a description if you like.
- Choose "Public" or "Private" based on your preference.
- Do not initialize the repository with a README, `.gitignore`, or license for this scenario.
- Click "Create repository".
#### 2. Launch an EC2 Instance
- Open AWS Management Console: Navigate to the EC2 dashboard.
- Launch a New Instance:
- Choose an Amazon Linux 2 AMI (or any Linux distribution you prefer).
- Select an instance type, such as `t2.micro`.
- Configure security groups to allow SSH access.
- Launch the instance and connect to it using SSH.
#### 3. Install Git on the EC2 Instance
- Connect to Your EC2 Instance via SSH:
ssh -i /path/to/your-key.pem ec2-user@your-ec2-instance-public-dns
- Install Git:
sudo yum update -y
sudo yum install git -y
- Verify Git Installation:
git --version
#### 4. Clone the GitHub Repository to EC2
- Clone the Repository:
- Navigate to the GitHub repository you created earlier and copy the HTTPS clone URL.
- In the terminal, clone the repository:
git clone https://github.com/your-username/ec2-git-demo.git
- Navigate to the Cloned Repository:
cd ec2-git-demo
#### 5. Check the Name of the Remote Repository
- Check the Remote Repository:
- Use the following command to list the remote repositories associated with your local Git repository:
git remote -v
- You should see the URL of the GitHub repository listed as `origin`.
#### 6. Create a File Locally
- Create a New File:
- Use the following command to create a new file in the repository:
echo "Hello from EC2!" > hello.txt
- Add the File to the Staging Area:
git add hello.txt
- Commit the File:
git commit -m "Add hello.txt file"
#### 7. Push the File to the Remote Repository
- Push the Changes:
- Push the committed changes to the GitHub repository:
git push origin main
#### 8. Verify the Changes on GitHub
- Go to GitHub:
- Navigate to your repository on GitHub.
- You should see the `hello.txt` file in the repository.
1. Validate SCM Polling:
- Commit a change to the source code repository used in the project.
- Wait for the next polling interval (e.g., 5 minutes) and check if Jenkins detects the change and automatically triggers a build.
2. Check Build Results:
- Once a build is triggered, check the build results on the project dashboard to ensure everything is working correctly.
### Conclusion
By following these steps, you have successfully set up a Jenkins project with Poll SCM build triggers. The project is configured to automatically check for changes in the source code repository and trigger builds as needed, ensuring continuous integration. This setup helps streamline the development process by automating builds based on code changes.
Poll SCM and Webhook are both mechanisms used to trigger automated builds in Jenkins based on changes in a source code repository, but they operate differently and are suited for different scenarios. Here's a breakdown of the differences between the two:
### 1. Trigger Mechanism
- Poll SCM:
- Jenkins periodically checks (polls) the source code repository at defined intervals (e.g., every 5 minutes) to see if there have been any changes.
- If changes are detected, Jenkins triggers a build.
- The polling schedule is defined using a cron-like expression in Jenkins.
- Webhook:
- A webhook is a push mechanism where the source code repository notifies Jenkins immediately whenever a change occurs.
- The repository sends an HTTP POST request to Jenkins with details about the change (e.g., a commit).
- Jenkins then triggers a build based on this notification.
### 2. Resource Usage
- Poll SCM:
- Polling can be resource-intensive, especially if there are many repositories or the polling interval is short.
- Jenkins repeatedly checks the repository even if no changes have occurred, which can lead to unnecessary load on both Jenkins and the repository server.
- Webhook:
- Webhooks are more efficient because they only trigger Jenkins when there is a change in the repository.
- No continuous checking is required, reducing the load on both Jenkins and the repository.
### 3. Real-time Response
- Poll SCM:
- Not real-time. There is a delay between when a change occurs and when Jenkins detects it, depending on the polling frequency.
- If the polling interval is set to a longer duration (e.g., once an hour), there could be significant delays in starting builds.
- Webhook:
- Real-time. Jenkins responds almost immediately after a change is pushed to the repository.
- This is ideal for scenarios where fast feedback is critical.
### 4. Configuration Complexity
- Poll SCM:
- Simpler to set up within Jenkins, especially if the repository doesn't support webhooks or if the network setup complicates webhook configuration.
- Requires only the configuration of a polling schedule within Jenkins.
- Webhook:
- Requires configuring the repository to send webhook notifications to Jenkins.
- Additional setup may be needed for security (e.g., tokens, firewalls) to allow the repository to communicate with Jenkins.
### 5. Use Cases
- Poll SCM:
- Suitable for environments where webhook support is unavailable or where network constraints prevent the use of webhooks.
- Useful for repositories that are less frequently updated or where the delay in build triggering is acceptable.
- Webhook:
- Ideal for environments where fast, real-time build triggering is needed.
- Preferred for repositories with frequent updates, as it reduces unnecessary load and provides immediate feedback.
### Summary
- Poll SCM involves Jenkins checking the repository at regular intervals, which can be resource-intensive and cause delays in build triggering.
- Webhooks allow the repository to notify Jenkins immediately when changes occur, leading to more efficient and real-time build triggers.
In general, webhooks are preferred for modern CI/CD pipelines due to their efficiency and immediacy, while Poll SCM remains a fallback option for environments where webhooks aren't feasible.
### Project Scenario: Configuring Jenkins with Webhook Build Triggers
Objective: Set up a Jenkins project that automatically triggers builds using a webhook from a GitHub repository. This scenario will cover creating the project, configuring jobs, setting up the webhook, and validating the setup.
### Step 1: Set Up Jenkins Project
Scenario: Create a new Jenkins project that will be triggered by a webhook when changes are pushed to a GitHub repository.
1. Access Jenkins Dashboard:
- Log in to Jenkins as an administrator.
2. Create a New Project:
- From the Jenkins dashboard, click `New Item`.
- Enter the project name as `Webhook_Project`.
- Select `Freestyle project` and click `OK`.
### Step 2: Configure Source Code Management (SCM)
Scenario: Configure the project to pull code from a GitHub repository.
1. Configure SCM:
- On the project configuration page, scroll down to the `Source Code Management` section.
- Select `Git`.
- Enter the repository URL (e.g., `https://github.com/your-repo/sample-project.git`).
- Add credentials if necessary for accessing the repository.
- Specify the branch to build (e.g., `*/main`).
- under Build Triggers select "GitHub hook trigger for GITScm polling"
### Step 3: Set Up Webhook in GitHub
Scenario: Configure a webhook in the GitHub repository to notify Jenkins whenever changes are pushed.
1. Access Your GitHub Repository:
- Go to your GitHub repository where you want to set up the webhook.
2. Navigate to Webhooks:
- Click on `Settings` in the repository.
- On the left sidebar, select `Webhooks`.
3. Add a New Webhook:
- Click `Add webhook`.
- In the `Payload URL`, enter the Jenkins webhook URL. This usually looks like:
http://<jenkins-server>/github-webhook/
Replace `<jenkins-server>` with your Jenkins server’s URL.
- Set the `Content type` to `application/json`.
- Choose `Just the push event` under `Which events would you like to trigger this webhook?`.
- Click `Add webhook` to save.
### Step 4: Add a Build Step
Scenario: Set up a simple build step to validate the build process.
1. Configure the Build Step:
- In the `Build` section of the Jenkins project configuration, click `Add build step` and select `Execute shell`.
- In the command box, enter:
echo "Building Webhook_Project"
2. Save the Configuration:
- Scroll down and click `Save` to apply the project configuration.
### Step 5: Validate Webhook Configuration
Scenario: Test and validate that the webhook is correctly set up and that Jenkins triggers builds when changes are pushed to the GitHub repository.
#### 1. Create a GitHub Repository
- Go to GitHub: Log in to your GitHub account.
- Create a New Repository:
- Click on the "New" button to create a new repository.
- Enter a repository name, for example, `ec2-git-demo`.
- You can add a description if you like.
- Choose "Public" or "Private" based on your preference.
- Do not initialize the repository with a README, `.gitignore`, or license for this scenario.
- Click "Create repository".
#### 2. Launch an EC2 Instance
- Open AWS Management Console: Navigate to the EC2 dashboard.
- Launch a New Instance:
- Choose an Amazon Linux 2 AMI (or any Linux distribution you prefer).
- Select an instance type, such as `t2.micro`.
- Configure security groups to allow SSH access.
- Launch the instance and connect to it using SSH.
#### 3. Install Git on the EC2 Instance
- Connect to Your EC2 Instance via SSH:
ssh -i /path/to/your-key.pem ec2-user@your-ec2-instance-public-dns
- Install Git:
sudo yum update -y
sudo yum install git -y
- Verify Git Installation:
git --version
#### 4. Clone the GitHub Repository to EC2
- Clone the Repository:
- Navigate to the GitHub repository you created earlier and copy the HTTPS clone URL.
- In the terminal, clone the repository:
git clone https://github.com/your-username/ec2-git-demo.git
- Navigate to the Cloned Repository:
cd ec2-git-demo
#### 5. Check the Name of the Remote Repository
- Check the Remote Repository:
- Use the following command to list the remote repositories associated with your local Git repository:
git remote -v
- You should see the URL of the GitHub repository listed as `origin`.
#### 6. Create a File Locally
- Create a New File:
- Use the following command to create a new file in the repository:
echo "Hello from EC2!" > hello.txt
- Add the File to the Staging Area:
git add hello.txt
- Commit the File:
git commit -m "Add hello.txt file"
#### 7. Push the File to the Remote Repository
- Push the Changes:
- Push the committed changes to the GitHub repository:
git push origin main
#### 8. Verify the Changes on GitHub
- Go to GitHub:
- Navigate to your repository on GitHub.
- You should see the `hello.txt` file in the repository.
1. Push a Change to GitHub:
- Make a small change to a file in your GitHub repository and commit the change.
- Push the changes to the repository.
2. Check Jenkins for Build Trigger:
- Go to the Jenkins dashboard and navigate to the `Webhook_Project`.
- Check if a new build was automatically triggered after the push to GitHub.
3. Review the Build Output:
- Once the build is complete, click on the build number and check the console output.
- Ensure the message "Building Webhook_Project" appears, indicating that the build step was executed.
### Conclusion
This project scenario demonstrates how to set up a Jenkins project with webhook-based build triggers from a GitHub repository. The setup allows Jenkins to automatically trigger builds whenever changes are pushed to the repository, providing a real-time CI/CD pipeline. Validation steps ensure that the webhook and build process are functioning correctly, ensuring a reliable and efficient development workflow.