DEV Community: Arief Warazuhudien

Embracing Operational-Centric Architecture in NodeJS Microservice Applications

Arief Warazuhudien — Sat, 02 Mar 2024 14:01:19 +0000

In the dynamic realm of software engineering, the architecture adopted for microservice applications plays a pivotal role in their operational efficiency and overall success. The move towards an operational-centric architecture signifies a strategic alignment with business functionalities, fostering a more intuitive and manageable development environment.

The Evolution Towards Operational-Centric Design

Historically, software architectures have evolved from monolithic designs to more granular, service-oriented patterns. This evolution reflects a broader industry shift towards agility, scalability, and continuous integration/deployment practices. Within this context, the operational-centric architecture for microservices emerges as a response to the need for more adaptable and business-aligned frameworks.

Drawing on principles from domain-driven design (DDD), this architectural style emphasizes the importance of reflecting business domains in software structures. It also incorporates lessons from service-oriented architecture (SOA) by delineating services based on business capabilities, thus promoting modularity and ease of maintenance.

Aligning Software with Business Objectives

An operational-centric architecture facilitates a direct correlation between software components and business operations, thereby enhancing the transparency and traceability of the application. It aids stakeholders from various backgrounds—be it technical or non-technical—to have a unified understanding of the application's structure and functionalities. This alignment not only simplifies the development and scaling processes but also streamlines communication across different teams, fostering a collaborative environment that is conducive to innovation and rapid iteration.

Implications for Microservice Applications

In the microservice ecosystem, where applications are decomposed into small, independently deployable services, an operational-centric approach provides a clear framework for organizing these services around distinct business functionalities. It encourages developers to think in terms of business outcomes, leading to more coherent and focused service design. Moreover, this architecture supports the principles of autonomy and decentralized governance intrinsic to microservices, enabling teams to develop, deploy, and scale their services independently.

In conclusion, adopting an operational-centric architecture in microservice applications represents a strategic alignment with contemporary software development paradigms. It underscores a commitment to business agility, service modularity, and team collaboration, setting a solid foundation for building resilient, user-centric applications that can adapt swiftly to changing business needs.

Leveraging Operational-Centric Architecture for Enhanced Microservice Efficacy

The operational-centric architecture in microservices is not just a structural choice—it's a strategic advantage. By organizing services around business operations, this architectural style enhances several key aspects of software development and operation, offering tangible benefits to both development teams and the end-users.

Enhanced Modularity and Scalability

One of the foremost advantages of an operational-centric architecture is the enhanced modularity it offers. Each service is designed around a specific set of operations, making it easier to understand, develop, test, and maintain. This modularity also translates to better scalability, as services can be scaled independently based on their specific demands and usage patterns, optimizing resource utilization and performance.

Improved Alignment with Business Objectives

Operational-centric architecture ensures that each microservice closely aligns with a specific business function or operation, facilitating clearer communication and better alignment between technical teams and business stakeholders. This alignment helps ensure that the software evolves in sync with business needs, supporting agile responses to market changes or new opportunities.

Increased Development Velocity and Team Autonomy

By breaking down the application into operationally focused microservices, teams can work on discrete components of the application in parallel, increasing development velocity. This structure supports the autonomy of development teams, allowing them to make decisions locally and respond more quickly to their specific challenges and requirements without waiting for broader consensus.

Simplified Maintenance and Troubleshooting

An operational-centric approach simplifies the maintenance of microservices by clearly delineating service boundaries and responsibilities. When issues arise, it's easier to pinpoint the affected service and address the problem without extensive cross-service impact assessments. This clear separation of concerns also aids in more straightforward troubleshooting and debugging processes.

Facilitated Evolution and Technological Agility

The decoupled nature of this architecture allows individual services to evolve independently, fostering technological agility. Teams can adopt new technologies, update frameworks, or refactor their services with minimal impact on the broader application ecosystem. This flexibility ensures that the application remains at the forefront of technological advancements and can quickly adapt to new technical opportunities or requirements.

The operational-centric architecture imbues microservice applications with the flexibility, scalability, and clarity needed to thrive in today's fast-paced and ever-changing technological landscape. By aligning software components with business operations, organizations can achieve a more responsive, robust, and user-centric application ecosystem.

Proposed Structure

The operational-centric architecture establishes a robust framework for microservice applications, delineating a clear path for structuring and managing services. This section outlines the recommended structure and concludes with key takeaways on implementing this architecture effectively.

Defining the Operational-Centric Structure

In the operational-centric architecture, each component is purposefully designed and organized to streamline development and enhance service management:

/microservice-app
    /assets
        /images
        style.css
        script.js
    /operations
        ${domain}-api.js
    /procedures
        ${domain}-dbm.js
    /renderers
        ${domain}-page.js
    /templates
        ${domain}.html
    .env
    package.json
    server.js

/assets: This directory is dedicated to static resources that the application may require, including images, stylesheets, and JavaScript files, facilitating a centralized resource hub for UI elements.
/operations: Central to this architecture, the operations directory houses logic files that directly correspond to business functionalities, such as ${domain}-api.js, ensuring that each service is distinctly focused on particular operational outcomes.
/procedures: Reflecting the data interaction layer, this directory encapsulates data access and manipulation logic within files like ${domain}-dbm.js, abstracting the intricacies of database operations and promoting reuse and modularity.
/renderers: This segment, crucial for generating user-facing content, includes scripts such as ${domain}-page.js that render data into HTML format, leveraging templates for dynamic content generation.
/templates: Serving as the foundation for view rendering, this directory stores HTML templates, such as ${domain}.html, which are instrumental in defining the structure and layout of rendered pages.

Implementing and Concluding Thoughts

Implementing an operational-centric architecture requires a thoughtful approach to defining and segregating functionalities based on business operations, ensuring that each microservice remains focused, coherent, and aligned with its intended purpose. The prescribed structure facilitates this by providing a clear organizational schema that delineates responsibilities and enhances service cohesion.

Conclusion

Adopting an operational-centric architecture in microservice applications offers a strategic blueprint for building scalable, maintainable, and business-aligned services. It underscores the importance of clarity and purpose in service design, advocating for a structure that mirrors business operations to enhance agility and responsiveness. By embracing this architectural framework, development teams can foster a more intuitive, flexible, and robust microservice ecosystem, poised to adapt and thrive amidst the ever-evolving technological and business landscapes.

Retrieving User Information from Jira using Groovy Script

Arief Warazuhudien — Tue, 08 Aug 2023 08:05:25 +0000

In today's interconnected tech ecosystem, automation and integration between platforms are of paramount importance. One such useful integration point is Jira, a popular issue and project tracking software developed by Atlassian. Developers often need to interface with Jira's API to automate or customize specific workflows.

In this article, we'll dissect a Groovy script snippet that makes an HTTP request to Jira's API to retrieve user information based on a user's email or name and then extract the accountId from the resulting JSON.

The Script Snippet:

def userResponse = httpRequest(
    authentication: 'JiraAuth',
    httpMode: 'GET',
    url: 'https://your-space.atlassian.net/rest/api/2/user/search?query=USER_EMAIL_OR_NAME'
)
def user = readJSON text: userResponse.content
def accountId = user[0].accountId

Understanding the Snippet:

HTTP Request:

The httpRequest function sends an HTTP GET request. Let's break down the parameters passed to it:

authentication: 'JiraAuth': This indicates that the request requires authentication, and 'JiraAuth' would be a predefined authentication method, possibly a token or user credentials specific to Jira.
httpMode: 'GET': This parameter specifies the type of HTTP method being used. In this case, it's a 'GET' request.
url: The provided URL is an endpoint of the Jira API that allows searching for users based on a query which is expected to be either the email or name of the user.

Reading the Response:

The readJSON function is used to parse the JSON response from the HTTP request. This parsed JSON is then stored in the user variable.

userResponse.content: This gets the actual content of the response, which is expected to be in JSON format.

Extracting the accountId:

user[0].accountId: The parsed JSON is expected to be an array of users. This line extracts the accountId of the first user in the list.

Practical Use Cases:

User Verification: By searching for users based on their emails or names, developers can verify if a particular user exists in the Jira system or not.

User Management Automation: By automating the process of fetching user details, larger scripts or programs can be built to manage users, such as assigning them to projects, groups, or roles based on certain criteria.

Audit and Reporting: This script can be incorporated into a more extensive system that audits user activities, checks for inactive users, or generates reports based on user interactions with Jira.

Conclusion:

The provided Groovy script snippet is a straightforward and effective way to communicate with Jira's API to retrieve user details. While it seems simple, the concept can be expanded and integrated into a wide variety of tasks and automations, making the developer's life easier and more efficient. If you're looking to integrate Jira with other platforms or automate specific Jira workflows, mastering such scripts is an excellent place to start.

Example of a shell script that uses cURL to retrieve & submit all the configurations for a project in JIRA

Arief Warazuhudien — Tue, 18 Jul 2023 15:13:30 +0000

Example of a shell script that uses cURL to retrieve all the configurations for a project in JIRA, including boards and workflows:

#!/bin/bash

# JIRA API URL and project key
JIRA_URL="https://your-jira-instance.com"
PROJECT_KEY="YOUR_PROJECT_KEY"

# JIRA API authentication
USERNAME="your-username"
API_TOKEN="your-api-token"

# Step 1: Authenticate and obtain the access token
AUTH_HEADER="Authorization: Basic $(echo -n "$USERNAME:$API_TOKEN" | base64)"
ACCESS_TOKEN=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/myself" | jq -r '.key')

# Step 2: Get the project ID
PROJECT_ID=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/project/$PROJECT_KEY" | jq -r '.id')

# Step 3: Retrieve the project details
PROJECT_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/project/$PROJECT_ID")

# Step 4: Get the workflow scheme ID
WORKFLOW_SCHEME_ID=$(echo "$PROJECT_DETAILS" | jq -r '.issueTypes[].workflowId')

# Step 5: Retrieve the workflow scheme details
WORKFLOW_SCHEME_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/workflowscheme/$WORKFLOW_SCHEME_ID")

# Step 6: Process and store the workflow details
WORKFLOW_DETAILS=$(echo "$WORKFLOW_SCHEME_DETAILS" | jq -r '.values[].workflow')

# Step 7: Retrieve all boards for the project
BOARD_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/agile/1.0/board?projectKeyOrId=$PROJECT_ID")

# Step 8: Process and store the board details
BOARD_IDS=$(echo "$BOARD_DETAILS" | jq -r '.values[].id')

# Output the configurations
echo "Project Details:"
echo "$PROJECT_DETAILS"
echo ""
echo "Workflow Scheme Details:"
echo "$WORKFLOW_SCHEME_DETAILS"
echo ""
echo "Workflow Details:"
echo "$WORKFLOW_DETAILS"
echo ""
echo "Board Details:"
echo "$BOARD_DETAILS"

To submit all the configurations retrieved from one project to a new blank project in JIRA, you can use the JIRA API to create the necessary configurations. Here's an example of a shell script that demonstrates this process:

#!/bin/bash

# JIRA API URL and project keys
JIRA_URL="https://your-jira-instance.com"
SOURCE_PROJECT_KEY="SOURCE_PROJECT_KEY"
TARGET_PROJECT_KEY="TARGET_PROJECT_KEY"

# JIRA API authentication
USERNAME="your-username"
API_TOKEN="your-api-token"

# Step 1: Authenticate and obtain the access token
AUTH_HEADER="Authorization: Basic $(echo -n "$USERNAME:$API_TOKEN" | base64)"
ACCESS_TOKEN=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/myself" | jq -r '.key')

# Step 2: Get the source project ID
SOURCE_PROJECT_ID=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/project/$SOURCE_PROJECT_KEY" | jq -r '.id')

# Step 3: Retrieve the project details
PROJECT_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/project/$SOURCE_PROJECT_ID")

# Step 4: Get the workflow scheme ID
WORKFLOW_SCHEME_ID=$(echo "$PROJECT_DETAILS" | jq -r '.issueTypes[].workflowId')

# Step 5: Retrieve the workflow scheme details
WORKFLOW_SCHEME_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/api/2/workflowscheme/$WORKFLOW_SCHEME_ID")

# Step 6: Process and store the workflow details
WORKFLOW_DETAILS=$(echo "$WORKFLOW_SCHEME_DETAILS" | jq -r '.values[].workflow')

# Step 7: Retrieve all boards for the project
BOARD_DETAILS=$(curl -s -H "$AUTH_HEADER" "$JIRA_URL/rest/agile/1.0/board?projectKeyOrId=$SOURCE_PROJECT_ID")

# Step 8: Process and store the board details
BOARD_IDS=$(echo "$BOARD_DETAILS" | jq -r '.values[].id')

# Step 9: Create a new project
NEW_PROJECT_ID=$(curl -s -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" -d '{
  "key": "'"$TARGET_PROJECT_KEY"'",
  "name": "New Project",
  "projectTypeKey": "business",
  "projectTemplateKey": "com.atlassian.jira-core-project-templates:jira-core-project-management",
  "description": "New project created from template",
  "lead": "'"$USERNAME"'",
  "assigneeType": "PROJECT_LEAD",
  "avatarId": 10137
}' "$JIRA_URL/rest/api/2/project" | jq -r '.id')

# Step 10: Update the workflow scheme for the new project
curl -s -X PUT -H "$AUTH_HEADER" -H "Content-Type: application/json" -d '{
  "update": {
    "issueTypeMappings": [{
      "issueTypeId": "10001",
      "workflow": {
        "name": "New Workflow",
        "description": "New workflow created from template",
        "steps": [
          {
            "id": "1",
            "name": "To Do"
          },
          {
            "id": "2",
            "name": "In Progress"
          },
          {
            "id": "3",
            "name": "Done"
          }
        ],
        "transitions": [
          {
            "id": "11",
            "name": "Start Progress",
            "from": ["1"],
            "to": "2"
          },
          {
            "id": "21",
            "name": "Resolve Issue",
            "from": ["2"],
            "to": "3"
          }
        ]
      }
    }]
  }
}' "$JIRA_URL/rest/api/2/workflowscheme/$NEW_PROJECT_ID"

# Step 11: Copy boards to the new project
for BOARD_ID in $(echo "$BOARD_IDS"); do
  curl -s -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" -d '{
    "name": "New Board",
    "type": "scrum",
    "projectIds": ["'"$NEW_PROJECT_ID"'"],
    "filterId": "'"$BOARD_ID"'"
  }' "$JIRA_URL/rest/agile/1.0/board"
done

echo "New project with key '$TARGET_PROJECT_KEY' has been created and configured."

Opsi Konektivitas: Mengekspos NGINX ke Internet Publik & Tunnel antara JIRA dan NGINX

Arief Warazuhudien — Thu, 13 Jul 2023 06:13:30 +0000

Opsi Konektivitas: Mengekspos NGINX ke Internet Publik

Kelebihan:

Konfigurasi yang lebih sederhana: Dengan mengekspos NGINX ke internet publik, konfigurasi menjadi lebih mudah karena tidak memerlukan alat tambahan atau setup seperti tunnel.
Akses yang lancar: Dengan NGINX yang terbuka ke internet publik, tim jarak jauh atau pemangku kepentingan eksternal dapat dengan mudah mengakses Jenkins tanpa memerlukan langkah tambahan atau metode autentikasi.
Skalabilitas: Opsi ini menawarkan fleksibilitas dalam mengukur ukuran instansi Jenkins sesuai permintaan karena tidak ada batasan konektivitas terkait dengan tunneling.
Pembaruan real-time: Pembaruan dan perubahan yang dilakukan pada Jenkins langsung terlihat oleh semua pengguna yang mengakses melalui internet publik, memastikan kolaborasi dan visibilitas real-time.

Kekurangan:

Risiko keamanan: Mengekspos NGINX ke internet publik memperkenalkan potensi kerentanan keamanan. Ini meningkatkan bidang serangan, sehingga penting untuk menerapkan langkah-langkah keamanan yang kuat seperti firewall, kontrol akses, dan audit keamanan secara berkala.
Ketergantungan pada konektivitas internet: Ketersediaan dan keandalan konektivitas internet menjadi faktor kritis untuk mengakses Jenkins. Gangguan konektivitas dapat mengganggu akses dan berdampak pada produktivitas.
Peningkatan risiko serangan: Dengan mengekspos NGINX ke internet publik, risiko serangan DDoS, upaya bruteforce, dan aktivitas jahat lainnya meningkat. Tindakan keamanan yang kuat harus diterapkan untuk mengurangi risiko tersebut.
Tantangan kepatuhan: Tergantung pada industri dan persyaratan kepatuhan tertentu, mengekspos NGINX ke internet publik dapat melanggar beberapa peraturan. Organisasi harus mengevaluasi dengan hati-hati dan memastikan kepatuhan dengan standar perlindungan data dan privasi yang relevan.

Opsi Konektivitas: Tunnel antara JIRA dan NGINX

Kelebihan:

Keamanan yang ditingkatkan: Dengan menggunakan tunnel antara JIRA dan NGINX, komunikasi tetap terenkripsi dan aman, mengurangi risiko pelanggaran data atau akses tidak sah.
Kontrol atas akses: Tunneling memungkinkan organisasi untuk menetapkan kontrol akses khusus dan membatasi akses eksternal langsung ke Jenkins. Hanya pengguna atau tim yang diizinkan dengan akses tunnel yang dapat berinteraksi dengan Jenkins, meningkatkan keamanan secara keseluruhan.
Kepatuhan yang terjaga: Dengan menjaga Jenkins di dalam jaringan pribadi melalui tunnel, organisasi dapat memastikan kepatuhan dengan perlindungan data dan regulasi privasi secara lebih efektif.
Risiko yang berkurang dari serangan internet publik: Tunneling meminimalkan eksposur NGINX ke internet publik, mengurangi risiko serangan DDoS, upaya bruteforce, dan aktivitas jahat lainnya.

Kekurangan:

Kompleksitas yang meningkat: Menyiapkan dan memelihara tunnel antara JIRA dan NGINX melibatkan langkah konfigurasi tambahan dan pemeliharaan yang berkelanjutan. Diperlukan keahlian dan sumber daya untuk memastikan tunnel tetap berfungsi dan aman.
Akses jarak jauh yang terbatas: Tunneling membatasi akses jarak jauh langsung ke Jenkins, yang dapat menjadi tidak nyaman bagi tim jarak jauh atau pemangku kepentingan eksternal yang membutuhkan akses tanpa melalui tunnel.
Tantangan skalabilitas: Jika ada kebutuhan untuk mengukur ukuran instansi Jenkins berdasarkan permintaan, tunneling dapat memperkenalkan kendala konektivitas dan mempersulit proses tersebut. Tunnel atau konfigurasi tambahan mungkin diperlukan untuk mengakomodasi pertumbuhan.
Dampak kinerja yang mungkin: Tergantung pada kondisi jaringan dan kompleksitas pengaturan tunnel, mungkin ada sedikit dampak kinerja karena overhead yang diperkenalkan oleh proses tunneling.

Pilihan antara mengekspos NGINX ke internet publik atau menggunakan tunnel antara JIRA dan NGINX tergantung pada persyaratan spesifik, pertimbangan keamanan, dan kepatuhan yang diperlukan oleh organisasi. Penting untuk mengevaluasi faktor-faktor ini dengan cermat dan mengimplementasikan langkah-langkah yang sesuai untuk memastikan keseimbangan optimal antara aksesibilitas, keamanan, dan kinerja.

Automated Installation of Docker and Rancher with Docker Compose

Arief Warazuhudien — Wed, 12 Jul 2023 14:50:11 +0000

Introduction:

In this article, we will explore an automated installation script that installs Docker, sets up a Docker Compose configuration, and deploys the Rancher management platform. This script streamlines the process of installing these tools and allows you to quickly set up a Rancher environment for managing your Docker containers. Let's dive into the details of the installation script.

Automated Installation Script:

The following script automates the installation process:

#!/bin/bash

# Update package lists
sudo apt-get update

# Install required packages
sudo apt-get install -y ca-certificates curl gnupg

# Create directory for keyrings
sudo install -m 0755 -d /etc/apt/keyrings

# Download Docker GPG key and save it to the keyring directory
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Set appropriate permissions for the GPG key
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add Docker repository to APT sources
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update package lists with the new Docker repository
sudo apt-get update

# Install Docker packages
sudo apt-get install -y docker-ce docker-ce-cli containerd.io

# Add the current user to the docker group
sudo groupadd docker
sudo usermod -aG docker $USER

# Start a new shell with the docker group membership
newgrp docker

# Create a new Docker Compose configuration file
echo "version: '3'
services:
  rancher:
    image: rancher/rancher:latest
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
    privileged: true" > docker-compose.yaml

# Start the Rancher service defined in the Docker Compose file
docker-compose up -d

# Display command history
history

Explanation:

The installation script performs the following steps:

Updates the package lists and installs the necessary packages for the installation process.
Creates a directory for the Docker GPG key and downloads the key from the Docker repository.
Adds the Docker repository to the APT sources.
Updates the package lists to include the Docker repository.
Installs Docker packages.
Adds the current user to the docker group for Docker access.
Starts a new shell with the docker group membership.
Creates a Docker Compose configuration file named docker-compose.yaml with a Rancher service configuration.
Starts the Rancher service using Docker Compose, which deploys the Rancher management platform.
Displays the command history to track the executed commands.

Conclusion:

Automating the installation of Docker and Rancher using a script not only saves time but also ensures consistency in the setup process. By following the steps outlined in this article and using the provided installation script, you can easily set up a Rancher environment to manage your Docker containers. Feel free to customize the script further to meet your specific requirements and streamline your container management workflow.

Perbandingan Ubuntu dan Rocky Linux: Pilihan dalam Konteks Batasan Akses Kode Sumber RHEL

Arief Warazuhudien — Tue, 11 Jul 2023 03:50:54 +0000

https://www.webpronews.com/red-hat-takes-aim-at-rocky-linux-almalinux-restricts-rhel-code-access/

Berikut adalah saran dan perbandingan matriks antara Ubuntu dan Rocky Linux berdasarkan berita yang Anda sampaikan sebelumnya:

Saran:
Berdasarkan berita yang mengatakan bahwa Red Hat membatasi akses kode sumber RHEL ke CentOS Stream, yang berpotensi mempengaruhi distribusi turunan seperti Rocky Linux, berikut adalah saran yang diperbarui:

Pilih Ubuntu: Mengingat ketidakpastian seputar ketersediaan kode sumber RHEL, dan mempertimbangkan bahwa Ubuntu adalah distribusi Linux yang sudah mapan dan banyak digunakan dengan dukungan perangkat lunak yang luas, mungkin menjadi pilihan yang lebih dapat diandalkan. Ubuntu memiliki komunitas pengguna yang besar, menyediakan rilis reguler dengan opsi dukungan jangka panjang, dan menawarkan berbagai paket perangkat lunak dan dukungan pihak ketiga.

Perbandingan Matriks:
Berikut adalah perbandingan matriks yang diperbarui antara Ubuntu dan Rocky Linux, dengan mempertimbangkan berita hipotetis mengenai keputusan Red Hat:

Fitur	Ubuntu	Rocky Linux
Kemudahan Pengguna	Cocok untuk pemula, intuitif	Cocok untuk pengguna berpengalaman juga
Manajemen Paket	Manajemen paket Debian (apt)	Manajemen paket RHEL (RPM)
Repositori Perangkat Lunak	Repositori yang luas dan beragam	Mungkin terpengaruh oleh batasan akses kode sumber RHEL
Dukungan Komunitas	Komunitas besar dan aktif	Komunitas yang berkembang dengan potensi pengaruh dari batasan akses kode sumber RHEL
Siklus Rilis	Rilis reguler setiap enam bulan dengan versi LTS	Fokus dukungan stabil dan jangka panjang
Audiens Target	Pengguna umum dan perusahaan	Pengguna RHEL dan mereka yang mencari kompatibilitas RHEL (dengan potensi keterbatasan)
Lingkungan Desktop	Menawarkan berbagai varian (GNOME, KDE, dll.)	Tidak ada default tertentu, mendukung beberapa lingkungan
Dukungan Komersial	Tersedia melalui Canonical	Dukungan yang didorong oleh komunitas, potensi dukungan komersial

Mengingat potensi dampak dari batasan akses kode sumber RHEL terhadap Rocky Linux, penting untuk mengevaluasi implikasinya terhadap kompatibilitas yang sedang berlangsung dan dukungan komunitas. Ubuntu tetap menjadi pilihan yang kuat karena penggunaan yang luas, repositori perangkat lunak yang ekstensif, dan dukungan komunitas yang sudah mapan.

Batasan akses kode sumber RHEL dapat berdampak pada distro turunan RHEL seperti Rocky Linux

Keamanan: Dengan akses terbatas terhadap kode sumber RHEL, distro turunan seperti Rocky Linux mungkin menghadapi kesulitan dalam menutupi kerentanan keamanan yang muncul di masa depan. Keterbatasan ini dapat menghambat kemampuan untuk secara cepat dan efisien memperbaiki dan mengamankan sistem operasi. Dalam hal keamanan, distribusi yang memiliki akses terbuka ke kode sumber RHEL, seperti CentOS Stream sebelumnya, dapat memberikan keuntungan lebih besar dalam mengidentifikasi, memperbaiki, dan mendistribusikan pembaruan keamanan yang relevan.

Dukungan Komunitas: Batasan akses kode sumber RHEL dapat mempengaruhi dukungan komunitas yang ada di sekitar distro turunan RHEL, seperti Rocky Linux. Komunitas pengembang dan pengguna dapat menghadapi tantangan dalam menavigasi dan mengatasi masalah yang mungkin timbul, terutama dalam hal keamanan. Dalam hal ini, distribusi yang mempertahankan akses terbuka ke kode sumber RHEL mungkin memiliki komunitas yang lebih kuat dan berpengalaman dalam memperbaiki dan mengatasi masalah keamanan.

Pembaruan dan Peningkatan: Dengan akses terbatas terhadap kode sumber RHEL, distro turunan seperti Rocky Linux mungkin menghadapi kendala dalam pembaruan perangkat lunak dan peningkatan fitur. Kemampuan untuk mengikuti perkembangan terbaru, memperbaiki bug, dan mengadopsi fitur baru dari RHEL mungkin terbatas. Ini dapat mempengaruhi kemampuan untuk menjaga kepatuhan dan kompatibilitas dengan lingkungan perusahaan yang mengandalkan RHEL.

How to call Jenkins API

Arief Warazuhudien — Fri, 09 Jun 2023 03:45:24 +0000

Jenkins is a popular automation server that provides an API for interacting with its features programmatically. By making HTTP requests to Jenkins API endpoints, you can automate various tasks and integrate Jenkins with other systems or scripts. In this guide, we'll explore how to use the curl command-line tool to interact with Jenkins API.

Before making API requests, you'll need to obtain an API token from Jenkins. The API token acts as a credential to authenticate your requests. Here's how you can generate an API token:

Log in to Jenkins using your Jenkins credentials.
Click on your username or the user icon in the top-right corner of the Jenkins interface to access your user profile.
Locate the "Configure" or "Configure User" option and click on it.
Look for the section related to API tokens, typically labeled as "API Token" or similar.
Click on the "Add new Token" or similar button to generate a new API token.
Provide any necessary authentication or password to proceed.
Once the API token is generated, copy and securely store it as it may not be displayed again.

With the API token in hand, you can now use curl to make API requests to Jenkins. Here's an example command to call a Jenkins API endpoint:

curl -s -X GET -u ${USERNAME}:${API_TOKEN} ${JENKINS_URL}/${API_ENDPOINT}

Let's break down the command:

-s makes curl silent, disabling the progress meter for script-friendly output.
-X GET specifies the HTTP request method as GET. You can replace GET with other HTTP methods like POST, PUT, or DELETE depending on the desired action.
-u ${USERNAME}:${API_TOKEN} provides the basic authentication credentials. Replace ${USERNAME} with your Jenkins username and ${API_TOKEN} with the API token you generated earlier.
${JENKINS_URL} should be replaced with the base URL of your Jenkins instance.
${API_ENDPOINT} represents the specific API endpoint you want to access. For example, to retrieve information about a job, you could use /job/{jobName}/api/json.

By executing this curl command, you can retrieve data or perform actions through Jenkins API. The response from Jenkins will be displayed in the command output.

Remember to consult the Jenkins API documentation or your Jenkins administrator for details about available endpoints, request parameters, and response formats specific to your Jenkins installation.

In summary, by leveraging curl and the Jenkins API token, you can easily automate and integrate Jenkins with your scripts or external applications.

Saving and Loading Docker Images

Arief Warazuhudien — Thu, 16 Mar 2023 09:26:58 +0000

Docker has become a popular platform for building, shipping, and running applications in containers. Docker containers are lightweight and portable, making them ideal for developers and system administrators who need to deploy applications quickly and efficiently.

One of the key features of Docker is the ability to create and manage images, which are the building blocks of containers. Docker images are read-only templates that contain all the necessary files, dependencies, and configurations to run an application. Images can be used to create one or more containers, which can be started, stopped, and deleted as needed.

To share Docker images between machines or with other users, they can be pushed to a Docker registry, such as Docker Hub. This allows users to easily share their images with others, deploy them to different environments, and collaborate on applications.

However, in some cases, users may need to distribute Docker images traditionally or without an internet connection. In these situations, the method of saving and loading images to a file can be very useful. Saving Docker images to a file allows users to create a portable, self-contained image archive that can be distributed via USB drives, DVDs, or other physical media.

This can be particularly useful for organizations that need to deploy Docker images to remote or disconnected environments, such as ships, airplanes, or rural areas with limited connectivity. By saving images to a file, users can easily transport the images to these locations and load them into Docker on the target machine.

Saving Docker Images to a File

Open a terminal window or command prompt.

Run the following command to save the Docker image to a file:

docker save -o <file-name.tar> <image-name>

Replace with the name you want to give the saved file and with the name of the Docker image you want to save.

The above command will save the Docker image as a tar file in your current working directory.

To verify that the image has been saved correctly, you can run the following command:

ls -l <file-name.tar>

This will display the file size and other information about the saved file.

Loading Docker Images from a File

Copy the saved file to the target machine.

Open a terminal window or command prompt on the target machine.

Run the following command to load the Docker image from the saved file:

docker load -i <file-name.tar>

Replace with the name of the saved file.

The above command will load the Docker image from the saved file into the local Docker image repository on the target machine. You can then use the image as you normally would.

To verify that the image has been loaded correctly, you can run the following command:

docker images

This will display a list of all the Docker images in the local repository, including the newly loaded image.

Conclusion

In summary, saving and loading Docker images to a file is a simple and effective way to distribute Docker images traditionally or in offline environments. By following these steps, users can easily transport their images, create backups, and deploy Docker applications across a wide range of environments.

How to Manage Logs in Dockerized Applications: Redirecting Output to Files and Handling Log Rotation

Arief Warazuhudien — Thu, 16 Mar 2023 02:40:41 +0000

Docker has become a popular tool for packaging applications and deploying them in a portable manner across different environments. However, it is important to ensure that the applications running in Docker containers are properly monitored and their logs are managed effectively.

By default, Docker containers write their logs to the standard output (stdout) and standard error (stderr). This can be useful for debugging and troubleshooting, but it is not a recommended approach for managing logs in production environments.

In production environments, it is typically necessary to redirect the logs to a file and handle log rotation to prevent the log files from becoming too large and consuming too much disk space. This can be achieved by configuring the Docker logging driver to write logs to a file and specifying the maximum size of each log file and the maximum number of log files to keep.

Proper log management can provide a number of benefits, including improved system performance, faster troubleshooting, and better security. By following best practices for managing logs in Dockerized applications, you can ensure that your applications are running smoothly and that any issues are quickly identified and resolved.

Redirecting logs to a file

To redirect logs to a file in Docker, you can use the --log-driver and --log-opt options when running the container. Here's an example command:

docker run --log-driver=local --log-opt max-size=10m --log-opt max-file=3 my-dockerized-app

In this command, we are using the local logging driver to redirect logs to a file on the local filesystem. We are also specifying that log files should be no larger than 10 MB (max-size=10m) and that a maximum of 3 log files should be kept (max-file=3).

You can adjust these options to suit your needs. For example, you might want to use a different logging driver or specify a different maximum log file size.

Handling log rotation

Once logs are being written to a file, it's important to handle log rotation to prevent log files from becoming too large and consuming too much disk space. There are a few ways to handle log rotation in Docker, including using a log rotation tool or configuring the logging driver to handle it.

One popular tool for log rotation is logrotate, which is available on many Linux systems. To use logrotate, you can create a configuration file that specifies the log files to rotate and how often to rotate them. Here's an example configuration file:

/path/to/log/file {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}

In this example, we are specifying that the log file at /path/to/log/file should be rotated daily (daily), with a maximum of 7 rotated log files (rotate 7). We are also compressing rotated log files (compress), delaying compression until the next rotation (delaycompress), and allowing rotation to proceed even if the log file is missing (missingok). Finally, we are notifying if the log file is empty after rotation (notifempty).

You can adjust these options to suit your needs. Once you have created a configuration file, you can run logrotate manually or configure it to run automatically using a cron job.

Alternatively, you can configure the Docker logging driver to handle log rotation for you. For example, you might use the json-file logging driver with the max-size and max-file options, as we saw earlier. When the maximum log file size or number of log files is reached, the logging driver will automatically rotate the log files for you.

Conclusion

Redirecting logs to a file and handling log rotation are important steps for managing Dockerized applications in production environments. By following best practices for log management, you can ensure that your applications are running smoothly and that any issues are quickly identified and resolved.

Combining Jenkins Pipeline and ArgoCD

Arief Warazuhudien — Tue, 14 Mar 2023 22:51:06 +0000

As organizations move to adopt cloud-native technologies and architectures, deploying applications to Kubernetes clusters has become increasingly complex. There are many moving parts involved in the deployment process, from building the container images to deploying them to Kubernetes and managing the infrastructure.

To manage this complexity, organizations have turned to tools like Jenkins Pipeline and ArgoCD to automate the deployment process and manage the infrastructure as code. Jenkins Pipeline provides a way to automate and orchestrate the continuous delivery pipeline, while ArgoCD provides a declarative way to manage deployments using GitOps principles.

Combining Jenkins Pipeline and ArgoCD can provide several benefits to organizations that are deploying applications to Kubernetes clusters. It can help to automate the entire deployment process, from code check-in to deployment to Kubernetes, while also providing scalability, improved collaboration, consistency and reliability, and visibility and monitoring into the deployment process.

In this way, the combination of Jenkins Pipeline and ArgoCD can help organizations to manage the complexity of deploying applications to Kubernetes clusters, while also providing a way to maintain consistency, reliability, and visibility into the deployment process.

Several benefits to organizations

Combining Jenkins Pipeline and ArgoCD can provide several benefits to organizations that are deploying applications to Kubernetes clusters:

Automated continuous delivery: ArgoCD provides a declarative way to manage deployments using GitOps principles, while Jenkins Pipeline provides a way to automate and orchestrate the continuous delivery pipeline. Combining these two tools allows organizations to automate the entire deployment process, from code check-in to deployment to Kubernetes.
Scalability: Kubernetes is designed to scale horizontally, and with that comes the challenge of managing multiple environments and applications across multiple clusters. ArgoCD and Jenkins Pipeline can help to automate the deployment process and provide a way to manage the scale of the deployment process.
Improved collaboration: With GitOps principles, changes to the infrastructure can be made through a pull request in Git, making it easier for teams to collaborate on changes. Jenkins Pipeline and ArgoCD can help to automate the process of merging these changes and deploying them to the Kubernetes cluster.
Consistency and reliability: With ArgoCD, the desired state of the infrastructure is defined in a Git repository, making it easier to maintain a consistent and reliable infrastructure. Jenkins Pipeline can help to automate the process of applying these changes to the Kubernetes cluster, ensuring that the infrastructure is always in the desired state.
Visibility and monitoring: ArgoCD provides a UI for monitoring and managing deployments, while Jenkins Pipeline provides visibility into the deployment process. Combining these two tools allows organizations to have a complete view of the deployment process, from code check-in to deployment to Kubernetes.

Overall, combining Jenkins Pipeline and ArgoCD can help organizations to automate the deployment process, scale the deployment process, improve collaboration, maintain consistency and reliability, and provide visibility and monitoring into the deployment process.

Jenkins & ArgoCD Roles

Jenkins Pipeline and ArgoCD each play distinct roles in the deployment process and provide different benefits to organizations.

Jenkins Pipeline is a tool for automating and orchestrating the continuous delivery pipeline. It provides a way to define and execute the steps of the pipeline, including building the application, testing it, packaging it into a container image, and deploying it to Kubernetes. Jenkins Pipeline is highly configurable and can be extended with plugins, making it a flexible tool for automating the deployment process.

ArgoCD, on the other hand, is a tool for managing deployments to Kubernetes clusters using GitOps principles. It provides a declarative way to manage the desired state of the infrastructure, with the desired state defined in a Git repository. ArgoCD continuously monitors the Kubernetes cluster and ensures that the current state matches the desired state, making it easier to maintain a consistent and reliable infrastructure. ArgoCD also provides a UI for monitoring and managing deployments, making it easier to visualize the deployment process and identify issues.

Together, Jenkins Pipeline and ArgoCD can provide end-to-end automation for deploying applications to Kubernetes clusters. Jenkins Pipeline handles the build, test, and package steps of the deployment process, while ArgoCD handles the deployment and management of the infrastructure. By combining these two tools, organizations can automate the entire deployment process and maintain a consistent and reliable infrastructure, all while providing visibility and monitoring into the deployment process.

Pipeline Example

In this example, we will compare two Jenkins Pipeline scripts for deploying an application to a Kubernetes cluster. The first script deploys the application without using ArgoCD, while the second script deploys the application using ArgoCD.

pipeline {
  agent any

  stages {
    stage('Build') {
      steps {
        sh 'docker build -t myorg/myapp:${BUILD_NUMBER} .'
      }
    }

    stage('Push to Registry') {
      steps {
        withCredentials([usernamePassword(credentialsId: 'registry-creds', usernameVariable: 'REGISTRY_USERNAME', passwordVariable: 'REGISTRY_PASSWORD')]) {
          sh "docker login -u ${REGISTRY_USERNAME} -p ${REGISTRY_PASSWORD} myregistry.example.com"
        }
        sh "docker push myorg/myapp:${BUILD_NUMBER}"
      }
    }

    stage('Deploy to Kubernetes') {
      steps {
        sh 'kubectl apply -f kubernetes/deployment.yaml'
        sh 'kubectl apply -f kubernetes/service.yaml'
      }
    }
  }
}

The first script uses Kubernetes YAML files to deploy the application. It builds a Docker image for the application, pushes the image to a Docker registry, and deploys the application to Kubernetes using the kubectl apply command to apply the Kubernetes YAML files for the deployment and service.

pipeline {
  agent any

  environment {
    ARGOCDSERVER = "https://argocd-server.example.com"
    ARGOCDPROJECT = "my-project"
    ARGOCDAPP = "my-app"
    K8SCONTEXT = "my-k8s-context"
    K8SNAMESPACE = "my-namespace"
    ARGOCDSYNCOPTIONS = "--sync-policy=auto --prune"
  }

  stages {
    stage('Deploy') {
      steps {
        script {
          def argocdToken = credentials('argocd-token')

          def appSpecFile = readFile("argocd/myapp.yaml")

          def argocd = new Argocd(server: ARGOCDSERVER, token: argocdToken)
          argocd.createApplication(appSpecFile, project: ARGOCDPROJECT)
          argocd.syncApplication(ARGOCDAPP, ARGOCDSYNCOPTIONS)
        }
      }
    }
  }
}

The second script uses ArgoCD to deploy the application. It defines the ArgoCD server URL, token, project, and application name, as well as the Kubernetes context and namespace where the application will be deployed. The ArgoCD Application manifest is defined in a YAML file, which is read into the script using the readFile function. The script then uses the Argocd class to create the application in ArgoCD and sync it to the Kubernetes cluster using the specified sync options.

Yaml Example

In this example, we will compare the use of Kubernetes YAML files and ArgoCD YAML application manifests for deploying an application to a Kubernetes cluster.

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myorg/myapp:latest
        ports:
        - containerPort: 8080
        env:
        - name: MYAPP_ENV
          value: "prod"

service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  selector:
    app: myapp
  ports:
  - name: http
    port: 80
    targetPort: 8080
  type: LoadBalancer

myapp.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  project: default
  source:
    repoURL: https://github.com/myorg/myapp.git
    targetRevision: HEAD
    path: kubernetes/overlays/dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  syncOptions:
    - --skip-hooks
  helm:
    valueFiles:
      - values.yaml

Conclusion

In conclusion, both Kubernetes YAML files and ArgoCD provide declarative ways to manage deployments to Kubernetes clusters. When you define a Kubernetes YAML file for a deployment, you are defining the desired state of the infrastructure, and when you apply that YAML file using kubectl apply, Kubernetes will ensure that the current state of the infrastructure matches the desired state.

However, while Kubernetes YAML files are also declarative, using them for managing deployments can be challenging when you have multiple environments and applications across multiple clusters. Kubernetes YAML files require manual synchronization and deployment, which can be time-consuming and error-prone.

ArgoCD provides a way to manage deployments using GitOps principles, which enables automated continuous delivery and provides a UI for monitoring and managing deployments. By using ArgoCD, you can define the desired state of the infrastructure in a Git repository and let ArgoCD handle the deployment process. This makes it easier to automate the deployment process and ensures that the infrastructure is always in the desired state.

Overall, while both approaches are declarative, using ArgoCD can provide a more streamlined and automated approach to managing deployments to Kubernetes clusters, making it easier to maintain a consistent and reliable infrastructure.

Vagrant for Infrastructure Development

Arief Warazuhudien — Tue, 14 Mar 2023 21:54:12 +0000

Infrastructure management is a critical part of any software development project, and there are many tools available to help manage and automate infrastructure. Three popular tools are Vagrant, Terraform, and Ansible. Each tool has its strengths and weaknesses, and choosing the right tool depends on your specific use case.

Here's a comparison matrix of Vagrant, Terraform, and Ansible:

Tool	Purpose	Type	Language	Platform Support
Vagrant	Build and manage development environments	Configuration management	Ruby	Local VMs, Cloud providers
Terraform	Build and manage infrastructure at scale	Infrastructure as code	HashiCorp Configuration Language (HCL)	Cloud providers, On-premises data centers
Ansible	Configure and manage infrastructure and applications	Configuration management	YAML	Linux, Windows, Network devices

Vagrant is a tool for building and managing development environments. It allows you to create and manage lightweight, reproducible virtual machines or containers on your local machine or in the cloud. Vagrant is useful for development and testing environments, allowing developers to quickly set up and tear down environments with specific configurations.

Terraform, on the other hand, is a tool for building and managing infrastructure at scale. It allows you to define and manage infrastructure as code, in a declarative language, and then creates and manages that infrastructure across different cloud providers or on-premises data centers. Terraform can manage resources such as virtual machines, networks, storage, and more.

Ansible is a tool for configuring and managing infrastructure and applications. It allows you to automate tasks such as server provisioning, software installation, and configuration management. Ansible uses YAML for its playbooks and modules, making it easy to write and maintain automation scripts.

When it comes to choosing a tool for development environments, Vagrant is the clear winner. Here are a few reasons why:

Easy setup and configuration

Vagrant allows developers to easily set up and configure development environments with specific software versions and dependencies. This makes it easy to create a consistent environment across the team, reducing the risk of compatibility issues and other problems.

Reproducibility

Vagrant provides a way to create and manage virtual machines or containers that can be easily reproduced across different machines or environments. This means that developers can create a development environment once and then share it with others, or deploy it to a production environment with confidence that it will work as expected.

Isolation

Vagrant provides a way to isolate development environments from the host machine and other environments. This means that developers can experiment with different configurations and software versions without affecting their host machine or other environments.

Cloud provider support

Vagrant supports a variety of cloud providers, such as AWS, Azure, and Google Cloud, making it easy to create and manage development environments in the cloud. This is particularly useful for remote teams or teams working on distributed projects.

In conclusion, Vagrant is a great tool for creating and managing development environments. It provides an easy-to-use interface for setting up and configuring virtual machines or containers, and allows developers to experiment with different configurations and software versions in a safe and isolated environment. With its support for cloud providers, Vagrant is a powerful tool for remote teams or teams working on distributed projects.

Combining Jenkins Pipeline, Terraform, and Ansible

Arief Warazuhudien — Tue, 14 Mar 2023 21:44:24 +0000

Infrastructure as Code (IaC) has become a popular approach to manage and provision infrastructure. It enables teams to manage infrastructure as code and use version control systems to track changes. However, implementing IaC can be complex and involve multiple tools and platforms. This is where Jenkins Pipeline, Terraform, and Ansible come in to simplify and automate infrastructure management.

Jenkins Pipeline is an extensible platform for automating software delivery pipelines. It provides a flexible way to define continuous delivery pipelines as code, allowing you to define the entire software delivery process from code commit to deployment. Terraform is a popular open-source tool for building, changing, and versioning infrastructure. It enables teams to describe their infrastructure as code and automate the provisioning of resources. Ansible is an open-source automation tool for configuring and managing computers and network devices. It allows you to automate complex IT tasks, from application deployment to network automation.

Combining Jenkins Pipeline, Terraform, and Ansible allows you to manage infrastructure as code, automate the provisioning and configuration of resources, and streamline your continuous delivery pipeline.

To provision a virtual machine with an application installed, you can use Terraform to define the virtual machine resource and Ansible to install the application.
Terraform allows you to define the infrastructure as code and automate the provisioning of resources.
Ansible allows you to automate the configuration and management of computers and network devices, making it an ideal tool for installing and configuring software on virtual machines.
Jenkins Pipeline can automate the entire process, from provisioning the virtual machine to installing the application, making it faster, more reliable, and more efficient.
By using Terraform, Ansible, and Jenkins Pipeline together, you can automate the delivery of software, manage infrastructure as code, and achieve greater efficiency and consistency in your infrastructure management processes.

Let's take a look at an example of how to use these tools together. Suppose you want to provision a virtual machine with PostgreSQL installed. You can use Terraform to define the virtual machine resource and Ansible to install PostgreSQL. You can then use Jenkins Pipeline to automate the entire process, from provisioning the virtual machine to installing PostgreSQL.

The Terraform configuration file defines the virtual machine resource, and the Ansible playbook installs PostgreSQL. The Jenkins Pipeline script automates the entire process, using Terraform and Ansible to provision and configure the virtual machine.

pipeline {
    agent any

    stages {
        stage('Terraform Apply') {
            steps {
                sh 'terraform init'
                sh 'terraform apply -auto-approve'
            }
        }
        stage('Ansible Provisioning') {
            steps {
                ansiblePlaybook credentialsId: 'ansible-ssh', inventory: 'localhost,', playbook: 'postgres.yml'
            }
        }
    }

}

The Jenkins Pipeline script has two stages. The first stage applies the Terraform configuration to create the virtual machine, and the second stage runs the Ansible playbook to install PostgreSQL. The ansiblePlaybook command is used to run the playbook using the ansible-ssh credentials.

Teraform script:

# define provider
provider "virtualbox" {}

# define instance
resource "virtualbox_vm" "postgres" {
  name   = "postgres"
  memory = 2048
  vram   = 16

  # create private network for postgres to listen on
  network_interface {
    hostonly_adapter = "vboxnet0"
  }

}

Ansible script:

- hosts: all
  become: true
  tasks:
  - name: Install PostgreSQL
    apt:
      name: postgresql
      update_cache: yes
    notify:
    - start postgresql service

  - name: Start PostgreSQL service
    service:
      name: postgresql
      state: started

By using Jenkins Pipeline, Terraform, and Ansible together, you can automate the provisioning and configuration of infrastructure, making it faster, more reliable, and more efficient. You can define your entire infrastructure as code and use version control systems to track changes, making it easier to collaborate and manage complex infrastructure.