Posts Tagged ‘managing’

Deploying a Server and Managing a 10-Node Linux Infrastructure with Ansible

Friday, May 30th, 2025

File:Ansible Logo.png - Wikimedia Commons

As organizations grow, manually configuring and maintaining servers quickly becomes inefficient, error-prone, and unscalable. Ansible, a powerful open-source automation tool, allows sysadmins and DevOps engineers to automate server provisioning, configuration management, and application deployment across multiple nodes—making it ideal for managing a fleet of Linux servers.

In this article, you’ll learn how to deploy a server using Ansible and manage an infrastructure of 10 Linux servers with ease.


What Is Ansible?

Ansible is a suite of software tools that enables infrastructure as code. It is open-source and the suite includes software provisioning, configuration management, and application deployment functionality.Ansible is an agentless IT automation tool. It uses SSH to connect to remote machines and YAML-based playbooks to define automation tasks. With Ansible, you can:

  • Install and configure software packages
  • Enforce configuration consistency
  • Perform updates across nodes
  • Deploy applications
  • Orchestrate complex workflows
     

Pre-requisites

To follow this guide, you need:

  • A control node (the machine from which you run Ansible)
  • 10 Linux servers (can be VMs or physical machines)
  • SSH access from the control node to all servers
  • Python installed on the target machines (most Linux distros have this by default)
     

1. Install Ansible on the Control Node 

On Ubuntu / Debian Linux

# apt update sudo apt install ansible -y

Or for CentOS/RHEL

# yum install epel-release -y
# yum install ansible -y

Verify installation:

# ansible –version

2. Configure Your Inventory File

Ansible uses an inventory file to define which servers to manage. By default, this is located at /etc/ansible/hosts , but you can also create a custom one.

Create an inventory file hosts.ini

[webservers]
server1 ansible_host=192.168.1.101
server2 ansible_host=192.168.1.102
server3 ansible_host=192.168.1.103
[dbservers]
server4 ansible_host=192.168.1.104
[all:vars]
ansible_user=ansible_user
ansible_ssh_private_key_file=~/.ssh/id_rsa

You can also use hostnames if DNS is configured.

3. Test Connectivity

# ansible -i hosts.ini all -m ping

If everything is set up correctly, you should see pong responses from all servers.

4. Write Your First Playbook (Provisioning Example)

Create a file called server_setup.yml:


– name: Provision and configure Linux servers
  hosts: all
  become: yes
  tasks:

    – name: Update apt cache (Debian/Ubuntu)
      apt:
        update_cache: yes
      when: ansible_os_family == "Debian"

    – name: Install common packages
      package:
        name:
          – curl
          – git
          – htop
        state: present

    – name: Ensure Nginx is installed on webservers
      apt:
        name: nginx
        state: present
      when: "'webservers' in group_names"

    – name: Start and enable Nginx
      service:
        name: nginx
        state: started
        enabled: yes
      when: "'webservers' in group_names"
 

5. Run the Playbook

ansible-playbook -i hosts.ini server_setup.yml

Ansible will SSH into each server, execute the tasks, and return status messages.

6. Scaling to 10+ Servers

Managing a growing infrastructure is simple with Ansible:

  • Add new servers to hosts.ini
  • Reuse existing playbooks for setup
  • Use roles to modularize configuration (e.g., webserver, database, monitoring)
  • Schedule playbooks using cron or CI/CD pipelines (e.g., GitHub Actions, Jenkins)

7. Sample Ansible Project Structure

Organizing your Ansible project effectively is crucial for scalability and maintainability. Here's a sample recommended directory layout:

ansible-infra/
├── hosts.ini
├── server_setup.yml
├── roles/
│   ├── common/
│   │   ├── tasks/
│   │   │   └── main.yml
│   │   └── files/
│   └── webserver/
│       ├── tasks/
│       │   └── main.yml
│       └── templates/
└── group_vars/
    └── all.yml
 

Key Components:
 

  • ansible.cfg: Configuration file defining paths and settings.
  • inventories/: Directory containing environment-specific inventory files.
  • playbooks/: Directory for playbooks that define automation tasks.
  • roles/: Directory for reusable roles, each with its own tasks and variables.
  • requirements.yml: File listing external roles or collections.
     

For a detailed explanation of this structure, refer to the Ansible Documentation.

Visual Workflow (text) Diagram

To illustrate the workflow, here's a diagram depicting how Ansible interacts with your infrastructure:

+——————+        +——————+        +——————+
|   Control Node   |        |    Ansible      |        |   Managed Nodes  |
|  (Your Machine)  |        |  (Ansible Core) |        |  (10 Linux Servers)|
+——————+        +——————+        +——————+
        |                               |                                 |
        | SSH                      | Execute Playbooks  | Apply Configurations
        |                               |                                 |
        +————————->+————————->+

Workflow Steps:

  1. Control Node: You initiate commands from your local machine.

  2. Ansible Core: Ansible connects via SSH to each managed node.

  3. Managed Nodes: Ansible applies configurations as defined in your playbooks and roles.

This workflow ensures consistent and automated management of your infrastructure.

Best Practices

  • Use roles: Organize playbooks into reusable roles
     (ansible-galaxy init myrole)
  • Maintain version control: Keep playbooks and inventory in Git
  • Encrypt secrets: Use ansible-vault for secure credentials
  • Test in staging: Always validate changes before pushing to production

Conclusion

Ansible is a game-changer for managing Linux infrastructure. With a few simple playbooks, you can provision, configure, and maintain your servers consistently and securely.
For a 10-node infrastructure, it offers the perfect balance of simplicity and power—letting you scale efficiently without the overhead of agent-based solutions.

Some Helpful Subversion (SVN) general repository managing commands when you have to deal with Subversion on Debian Lenny servers

Friday, April 2nd, 2010

When I started with subversion it was a bit chaotic for me to grasp the subversion repository software basics.
Since I know there are many other people like me who are a novice into suversion I decided to post few of the
life saving (vital) subversion commands, I learned and use quite often this days.
This post should be considered as a very very overview of subversion commands. For more information please check, The subversion red-bean book here .
So here we go:
1. First To create repository after installing subversion you need to execute something similar to:

debian-server:~# svnadmin create --fs-type fsfs /path/to/repos/repo

In the above example /path/to/repos is actually the path to where you store the svn repositories, and repo is actually the repository name.
By the way note that by default svnadmin would create the repository in the fsfs database format, even if you skip the,
fsfs option.2. Let’s say you want to import some code into the newly created repository located in /path/to/repo via the local filesystem.
Here is how:

# imports in the subversion repositorydebian-server:~# svn import -m "importing directory in svn over local filesystem"
~/directory_to_import/ files:///path/to/repos/repo/trunk

In the forementioned example the, -m and the following text: “importing directory in svn over local filesystem” is for description of the importing data,
the ~/directory_to_import/ is the directory you prefer to import into the local repository, the code left,
files:///path/to/repo/trunk specifies that you want to import the data into the repository subdirectory “trunk”.

Then again let’s assume that you want to achieve a file import into a newly created repository through ssh + the apache mod_dav_svn

It’s pretty easy the above should be changed to:

debian-server:~# svn import -m "importing directory in svn over mod_dav_svn e.g. (svn+ssh)"
~/directory_to_import/ svn+ssh://user@host/path/to/repos/repo/trunk
of course it preliminary that you input a proper user and host or ip address as you have previously configured the mod_dav_svn, then again svn+ssh specifies the protocol type.

Now as we have imported our program source code into the repository, next it’s important to checkout the code to have a current copy of the source code.
3. To checkout code already existing in some repository in your subversion server via (svn+ssh) protocol, you need to execute some command similar to:

debian-server:~# svn co svn+ssh://user@host/path/to/repos/repo/trunk ~/checkout_into_directory/

Here again as a first protocol argument (svn+ssh://) it’s necessery to enter path/to/repos/repo/trunk and as a second argument to gsvn (the subversion command line client interface) we put ~/checkout_into_directory/ , it’s a nice idea to to create the checkout_into_directory beforehead.

Now if we have to checkout the code after we’ve been logged in the system and the repository database is locally stored on the same server as we are, we have to execute:

debian-server:~# svn co files://path/to/repos/repo/trunk ~/checkout_into_directory/

Take a note that in the example above I use the root user but possibly you would choose a non-privileged user, therefore you should have properly set both physical user account permissons on the subversion repository database (e.g. chown your /path/to/repos/repo/ and put your local user into the proper /etc/groups).

Another truly precious command that you will probably need to use on daily and hourly basis would probably be:
4. The listing of repository content cmd, in order to do that while locally logged on the server with the svn repository execute:

debian-server:~# svn list file:///path/to/repos/repo/trunk

I believe the above command is self-explanatory enough, in case if you plan to do file listing within the svn repository over (ssh+svn) here is how:

debian-server:~# svn list --verbose svn+ssh://user@host/path/to/repos/repo/trunk

Again, I won’t take the time to explain since the logic in the syntax is equal to the one exhibited beforehead.
5. Another handy thing to do with your subversion repository content after checkout is the subversion source repository update

the svn update The checkout will enable you to always synchronize your ~/checkout_into_directory to the latest stable version of the code within your svn repository.

So after the first checkout it would be good idea to use svn update and update your repository project source tree.
So here is how:

debian-server:~# svn update ~/checkout_into_directory/

So now as I have shown most basic operations with subversion, Lest important to show you is
6. How to delete source from a repository in subversion.

In order to delete some part from your subversion repository project source from the local filesystem use:
debian-server:~# svn delete files:///path/to/repos/repo/track/some_directory

This command would completely erradidacate some_directory from your example repo. Yet if you desire to delete a file specify a file instead of the some_directory

Now to accomplish the same delete operation via (svn+ssh) execute something like:

debian-server:~# svn delete svn+ssh://user@host/path/to/repos/repo/track/some_directory

Once again I won’t bother to explain the above example code, cause I believe it’s clear enough for everybody to understand.

7. To reverse your project code to some stable release of your source code existing in the repository you should use something like:

debian-serve~:# svn checkout -r 4 files:///path/to/repos/repo/trunk
This would checkout the project source to it's 4th release from the repository: repo

8. To commit code with changes in your subversion repository use a command like:

debian-server:~# svn commit -m "Some description text" some_directory/

The svn command line interface is also capable of svn copy and svn rename in order to either,
copy or rename commited source, however I won’t get into details on that just experiment and you’ll quickly master them.
9. Now one last thing I’m gonna tell you about is the subversion svn info command and svn status . This really useful command should be used to check information on your source tree after you have either checked it out or have used svn update to have the latest copy of it. This is an absolute necessity.

Here is how to check the information assigned about the version release and some other useful info for your source tree.

debian-server:~# svn info ~/check_into_directory
or you might type svn info without arguments as well
debian-server:~# svn info

Yet another useful one on project status is:

debian-server:~# svn status