Do you think IIT Guwahati certified course can help you in your career?
Introduction
Do you know what Puppet is? Puppet is a tool that helps us to manage and automate the configuration of servers. But do you know about Puppet Application Manager? No worries, in this blog, we will learn about Puppet Application Manager, how to use Puppet Application Manager, Puppet Application manager’s architecture, and Puppet Application Manager’s system requirements.
Here, we will discuss more about puppet application manager❓. Are you ready❓
What Is Puppet Application Manager❓
The Puppet Application Manager installation process installs a managed Kubernetes cluster. On this Kubernetes cluster, Puppet Comply runs, and Puppet Application Manager takes care of the cluster management.
You can set up Puppet Comply. You should keep track of the cluster's activity, update to the most recent version of the program, and back up your installation using the Puppet Application Manager UI.
How To Use Puppet Application Manager To Deploy Comply❓
When the cluster is prepared, use the Puppet Application Manager UI to upload your Comply license and provide any installation-specific configuration information that may be required. When ready, you can deploy the most recent version of Comply with a single click.
Architecture Overview
Puppet Application Manager is run on Kubernetes. We offer a variety of supported configurations for various use cases.
Puppet Application Manager can be used on Kubernetes clusters supported by Puppet or the customer. The architecture overview provided on this page assumes that Puppet Application Manager is running on Puppet-supported clusters due to potential variations in the architecture of customer-supported collections.
Standalone Architecture
In Standalone architecture, the data is stored directly on a disc and is optimized for systems with few resources. If necessary, you will need to remove additional software like Prometheus and Grafana to reduce resource consumption. Secondary nodes can be used to increase compute capacity, but this does not increase resilience because data is only stored on the node where a component service is running.
HA Architecture
Ceph is a distributed storage system with high scalability that provides object, block, and file storage. A High Availability (HA) architecture uses Ceph for distributed storage in the event of node failure and offers high availability for scheduling application services during failure. If specific services lack replicas and need to be rescheduled, there may still be a brief loss of availability (up to 10 minutes) for particular applications. Three primary nodes must be arranged in a cluster for a HA implementation. Secondary nodes allow for the addition of additional computing power.
Puppet Application Manager Architectures
Some of the essential parts of standalone and HA architectures are listed below, along with an explanation of how they interact.
Standalone architecture
Puppet Application Manager
Resides on a Linux host's cluster.
Application services, PostgreSQL, and the admin console are all components of the Puppet Application Manager application.
To obtain updates, Puppet Application Manager communicates outside the Linux host.
UI Ports
The application UI communicates with the Linux host on port 80/443.
The HTTPS UI for the admin console connects to the Linux host on port 8800.
Backplane and Internal Ports
The backplane ports 6783 (TCP or UDP) and 10250 are included (TCP).
In a single host, backplane ports can also be used for inter-process communication.
These ports (6781 (TCP), 6782 (TCP), and 6784 (TCP) are only used for inter-process communication within a single host (UDP).
Additional Default Ports
30900: Prometheus UI
30902: Grafana UI
30903: Alertmanager UI
HA Cluster Architecture
Control Plane (Primaries)
Many primary processors are able to handle application workloads.
Arranged as clusters on Linux hosts, each with a Ceph device or partition.
Each primary supports either PostgreSQL or the admin console and hosts Puppet Application Manager in addition to being able to run application services.
Workers (Secondaries)
Added to increase the capacity for carrying out application workloads.
Cluster-structured within Linux hosts.
Application Balancer
Workers and the control plane (primaries) can communicate with the balancer (secondaries).
Admin console HTTPS UI communication is received over port 8800.
Receives UI communication from the application over 80/443.
Internal APIs of network load balancers communicate with primary and secondary nodes over port 6443.
Internal ports
Backplane ports include 10250, 6783, 2379/2380 (TCP or UDP), and 6783. (TCP).
In a single host, backplane ports can also be used for inter-process communication.
These ports (6781 (TCP), 6782 (TCP), and 6784 (TCP) are only used for inter-process communication (Weave) within a single host (UDP).
Additional default ports
30900: Prometheus UI
30902: Grafana UI
30903: Alertmanager UI
PAM system requirements
PAM (Puppet Application Manager) can be added to a customer-supported cluster or installed on a Puppet-supported cluster. Verify that your system satisfies these requirements before installing PAM.
Customer-Supported Cluster Hardware Requirements
There is support for the following Kubernetes distributions:
👉Google Kubernetes Engine
👉AWS Elastic Kubernetes Service
If you use a different distribution, get in touch with Puppet Support to learn more about Puppet Application Manager compatibility.
Application requirements
Application
CPU
Memory
Storage
Ports
Continuous Delivery for Puppet Enterprise (PE)
3 CPU
8 GB
280 GB
Ingress, NodePort 8000
Puppet Comply
7 CPU
7 GB
35 GB
Ingress, NodePort 30303
Make sure your Kubernetes cluster satisfies the prerequisites:
👉Kubernetes version 1.19-1.23.
👉A standard storage class that supports movable storage.
👉A typical Ingress controller with WebSocket support (we have tested with Project Contour and NGINX).
👉Currently, Google Kubernetes Engine (GKE) clusters are tested and supported by us.
Puppet-supported HA cluster hardware requirements
Multiple servers are used in a high availability (HA) configuration to ensure availability in the event of a server failure. To maintain service availability, the vast majority of servers must be online. For each application, the suggested configurations are listed below.
Continuous Delivery for Puppet Enterprise (PE)
Three servers with the bare minimum specifications:
CPU
Memory
Storage
Open ports
6 CPU
10 GB
On an unformatted storage device, there is 100 GB.
For /var/log/apiserver, the Kubernetes audit logs are 1 GB.
100 extra gigabytes for /var/lib. It is not necessary to use separate filesystems, but you can if you must. Here is a general breakdown of usage for your reference:
👉2 GB for /var/lib/etcd
👉10 GB for /var/lib/rook (plus buffer)
👉32 GB for /var/lib/kubelet
👉40 GB for /var/lib/containerd
Note: The utilisation of the /var/lib/rook file system should be kept below 70%, according to the storage backend.
SSDs are recommended for /var/lib/etcd and /var/lib/rook.
Three servers with the bare minimum specifications:
CPU
Memory
Storage
Open ports
7 CPU
10 GB
On an unformatted storage device there is 100 GB.
For /var/log/apiserver, the Kubernetes audit logs are 1 GB.
100 extra gigabytes for /var/lib. It is not necessary to use separate filesystems, but you can if you must. Here is a general breakdown of usage for your reference:
👉2 GB for /var/lib/etcd
👉10 GB for /var/lib/rook (plus buffer)
👉32 GB for /var/lib/kubelet
👉40 GB for /var/lib/containerd
Note: The utilisation of the /var/lib/rook file system should be kept below 70%, according to the storage backend.
SSDs are recommended for /var/lib/etcd and /var/lib/rook.
Continuous Delivery for Puppet Enterprise (PE) and Puppet Comply
Three servers (referred to as primaries during installation) with the following minimum requirements:
CPU
Memory
Storage
Open ports
8 CPU
13 GB
On an unformatted storage device there is 100 GB.
For /var/log/apiserver, the Kubernetes audit logs are 1 GB.
100 extra gigabytes for /var/lib. Using separate filesystems is unnecessary, but you can if you must. Here is a general breakdown of usage for your reference:
👉2 GB for /var/lib/etcd
👉10 GB for /var/lib/rook (plus buffer)
👉32 GB for /var/lib/kubelet
👉40 GB for /var/lib/containerd
Note: The utilisation of the /var/lib/rook file system should be kept below 70%, according to the storage backend.
SSDs are recommended for /var/lib/etcd and /var/lib/rook.
Puppet Application Manager takes care of the cluster management on which puppet comply runs.
What is the use of Puppet?
With the aid of Puppet, you can manage and automate the configuration of servers. When using Puppet, specify the ideal state for the infrastructure systems you want to manage.
Why Puppet Comply?
Continuous compliance monitoring across hybrid infrastructure is possible with less manual labor and overhead.
What are CIS Benchmarks?
The Center for Internet Security (CIS) has developed a set of best practices called the CIS Benchmarks to assist security practitioners in implementing and managing their cybersecurity defenses.
What is puppet language?
Puppet provides the ability to define which software and configuration a system requires and then maintain a specified state after an initial setup.
Conclusion
In this blog, we studied SEO and explored some primary SEO techniques. You can refer to similar articles for more information
7+ registered 
