0% found this document useful (0 votes)
17 views6 pages

Section4 - Jenkins & Docker

The document outlines the process of executing Jenkins jobs on remote machines using SSH, detailing the setup of a remote Docker container with CentOS 7. It covers key steps including Dockerfile creation, SSH server installation, user and key configuration, and Jenkins integration for remote job execution. The guide emphasizes the importance of secure SSH connections and provides instructions for testing and verifying the setup.

Uploaded by

Sachin Sharma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views6 pages

Section4 - Jenkins & Docker

The document outlines the process of executing Jenkins jobs on remote machines using SSH, detailing the setup of a remote Docker container with CentOS 7. It covers key steps including Dockerfile creation, SSH server installation, user and key configuration, and Jenkins integration for remote job execution. The guide emphasizes the importance of secure SSH connections and provides instructions for testing and verifying the setup.

Uploaded by

Sachin Sharma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Remote Job Execution in Jenkins

Using SSH
Introduction
• Previous Jenkins jobs were executed locally within the Jenkins
container
• Need for executing jobs on remote machines using SSH
• Two approaches to setting up remote execution:
1. Creating a separate virtual machine as remote host
2. Creating another Docker container (recommended for learning)

Setting Up Remote Container with SSH


Base Setup

1. Create a new directory for the project files


2. Create a Dockerfile using CentOS 7 as base image

1. Understanding the CentOS 7 SSH Server Dockerfile

Base Image Selection and Repository


Configuration
The Dockerfile begins with selecting CentOS 7 as the base image:

FROM centos:7

This specific version selection is important because it ensures consistency in


our build environment. CentOS 7 is known for its stability and long-term
support.

The next crucial step involves updating the repository sources:

RUN sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*


&& \
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://
vault.centos.org|g' /etc/yum.repos.d/CentOS-*

This modification is necessary because CentOS 7 has reached end-of-life


status. The commands redirect package requests from the standard mirror
list to the vault.centos.org archive. This ensures we can still install packages
even though the distribution is no longer actively maintained. The sed
commands perform two important operations: 1. Comment out the mirrorlist
entries 2. Uncomment and update the baseurl to point to vault.centos.org
SSH Server Installation
The next section installs the OpenSSH server:

RUN yum -y install openssh-server

The -y flag automatically answers “yes” to installation prompts, making the


process non-interactive and suitable for automated builds. This single
command installs all necessary components for running an SSH server.

User Configuration and Security Setup


The Dockerfile then creates a user account and sets up the SSH
environment:

RUN useradd remote_user && \


echo "1234" | passwd remote_user --stdin && \
mkdir /home/remote_user/.ssh && \
chmod 700 /home/remote_user/.ssh

This multi-step process: 1. Creates a new user named ‘remote_user’ 2. Sets


a password (1234) using a non-interactive method 3. Creates the .ssh
directory in the user’s home folder 4. Sets restrictive permissions (700
means only the owner can read, write, or enter the directory)

SSH Key Configuration


The Dockerfile then sets up key-based authentication:

COPY remote-key.pub /home/remote_user/.ssh/authorized_keys


RUN chown remote_user:remote_user -R /home/remote_user/.ssh/ && \
chmod 600 /home/remote_user/.ssh/authorized_keys

This section: 1. Copies the public key from the build context into the
authorized_keys file 2. Sets appropriate ownership of the .ssh directory and
its contents 3. Sets secure permissions on the authorized_keys file (600
means only the owner can read or write)

SSH Server Initialization


The final technical setup involves generating SSH host keys:

RUN /usr/sbin/sshd-keygen

This creates the server’s unique cryptographic keys, which are essential for
establishing secure SSH connections.
Service Startup Configuration
The Dockerfile concludes with the command to run when the container
starts:

CMD /usr/sbin/sshd -D

The -D flag tells sshd to run in the foreground and not detach from the
terminal. This is crucial in a Docker container as the container will stop if
the main process terminates.

2. SSH Key Configuration

• Generate SSH key pair using command:

ssh-keygen -f remote-key

• Creates two files:

◦ remote-key (private key)


◦ remote-key.pub (public key)

Docker Compose Configuration


Adding Remote Host Service

remote_host:
container_name: remote-host
image: remote-host
build:
context: centos7
networks:
- net

Key Components:

• Service name: remote_host


• Container name: remote-host
• Custom image name: remote-host
• Build context: points to centos7 directory containing Dockerfile
• Network: same network as Jenkins container for communication

Building and Deploying


1. Build the custom image:
docker-compose build

1. Start the containers:

docker-compose up -d

Testing SSH Connection


Password Authentication

ssh remote_user@remote-host
# Enter password: 1234

Key-based Authentication

1. Copy private key to Jenkins container:

docker cp remote-key jenkins:/tmp/remote-key

1. Connect using private key:

ssh -i /tmp/remote-key remote_user@remote-host

Using Jenkins UI SSH


1. Jenkins Configuration:
◦ Navigate to Jenkins Dashboard -> Manage Jenkins -> Configure
System.
◦ Find the “SSH remote hosts” section and click “Add.”
2. Adding Credentials:
◦ Since SSH requires authentication, credentials need to be added.
Ricardo briefly touches the SSH host configuration but realizes he
needs to set up credentials first.
◦ He navigates to Jenkins Dashboard -> Credentials -> System ->
Global credentials (older Jenkins versions might have a slightly
different path).
◦ Click “Add Credentials.”
◦ Choose “Username with private key” as the credential type.
◦ Enter the username (remote_user in this case) created during the
remote host setup.
◦ Paste the contents of the private key file (remote-key located in
the centos7 directory). This key was likely generated earlier using
ssh-keyscan.
◦ Click “OK” to save the credentials.
3. Configuring the SSH Host:
◦ Return to Jenkins Dashboard -> Manage Jenkins -> Configure
System -> SSH remote hosts.
◦ Click “Add” (or edit the previously started configuration).
◦ Enter the hostname of the remote server (remote_host in this
example). This name resolves correctly inside the Docker network.
◦ Set the port to 22 (default SSH port).
◦ In the “Credentials” dropdown, select the remote_user credentials
created earlier.
◦ Click “Test Connection” to verify the configuration. A successful
connection confirms that Jenkins can now SSH into the remote
host using the provided credentials.
4. Saving Configuration:
◦ Click “Save” to apply the changes.

Key Concepts and Considerations:

• Docker Networking: The remote host is accessible via its hostname


only within the Docker network. This is crucial; attempting to connect
from outside the Docker network using the same hostname will fail.
• SSH Keys: SSH keys provide a more secure way to authenticate than
passwords. Ricardo uses a private key to establish the connection.
• Credentials Management: Jenkins stores the credentials securely,
allowing jobs to use them without exposing sensitive information.
• Testing the Connection: The “Test Connection” button is essential for
verifying the SSH configuration before using it in jobs.

How to execute a shell script on a


remote host via SSH using Jenkins
1. Creating a New Job:
◦ Click “New Item.”
◦ Give the job a name (e.g., remote-task).
◦ Select “Freestyle project” and click “OK.”
2. Configuring the Build Step:
◦ In the “Build” section, click “Add build step.”
◦ Choose “Execute shell script on remote host using SSH.”
◦ From the dropdown menu, select the SSH site configured in the
previous lesson (this dropdown contains all configured SSH
remote hosts). This automatically populates the connection details
(hostname, credentials).
3. Writing the Shell Script:
◦ In the “Command” text area, enter the shell script to be executed
on the remote host. The example script creates a file named
remote_file in the /tmp directory and writes a message including
the current date and time.

name="Ricardo"
echo "Hello, $name, current date and time is $(date)" > /tmp/
remote_file

4. Running the Job and Verifying the Output:


◦ Click “Save” to save the job configuration.
◦ Click “Build Now” to execute the job.
◦ Click “Console Output” to view the job’s execution details. This
output confirms that the SSH connection was established and the
script was executed.
5. Locating the Created File:
◦ The instructor then demonstrates checking for the file in several
locations:
▪ Inside the Jenkins container: The file is not there.
▪ On the host machine (outside any containers): The file is not
there.
▪ Inside the remote host container: The file is found here,
confirming that the script ran successfully on the remote
host.

Key Takeaways:

• SSH Plugin: The “Execute shell script on remote host using SSH”
build step utilizes the SSH plugin to connect to and interact with
remote hosts.
• Remote Execution: The script is executed on the remote host, not
within the Jenkins container. This is crucial for tasks that need to
interact with the remote host’s filesystem or services.
• File Location: The output file is created on the remote host in the
specified location (/tmp/ in the example).
• Troubleshooting: The console output provides valuable information
for debugging if the connection or script execution fails.

You might also like