Ansible and Puppet - Features to know

To deal with profoundly complex assignments, many Configuration Management tools has been introduced and the two most well known ones incorporate Ansible and Puppet. As per specialists, setup board is an essential procedure and is viewed as basic in the DevOps model to help ceaseless integration.

Short History of Puppet and Ansible :

Puppet:

The Puppet introduced in 2005. It is considered as the greatest player in the CM business with an amazing piece of the overall industry, it is written in Ruby programming language. Ruby is an open-source programming language that keeps running on all major working frameworks like Linux, Windows, Mac OS and so forth.

The enormous IT Companies are running their information servers utilizing puppet. There is one Enterprise version too accessible through PuppetLabs. In spite of the advantages, clients' grumble that Puppet is slow to adopt requested changes, such as adding new features and fixing bugs.

Ansible:

Ansible is introduced in 2012 by AnsibleWorks. It is possessed by the Red Hat now and witnesses a lot little piece of the pie than Puppet. It is characteristic on the grounds that Ansible is later while Puppet has been around much more. Puppet is an open source rendition and it has a venture release as well, Ansible Tower. Ansible written in Python programming language and intended to be lightweight with quick sending highlights.

Python built into most Unix and Linux systems, so setting up Ansible and running can be done fairly quickly. Being agentless is one of the features most touted in discussions about Ansible’s simplicity.  This agentless nature adds to the ease of setup and use. Also, the CLI accepts commands in almost any language, which is a big benefit. It incorporates many modules to help a more extensive number of reconciliations, as AWS and that's just the beginning.

Contrasts in course of action and utilization of Puppet and ansible:

Puppet is anything but difficult to introduce and utilize. Puppet is model-driven, built with systems administrators in mind. It depends on the customer server engineering and you may introduce Puppet on different servers together.

Ansible has an ace and no operators running on the customer machines, most capacities performe over SSH convention. It is very straightforward, agentless and utilizes YAML punctuation. The mind boggling errands are overseen in arrangement documents named as playbooks and directions can be written in practically any programming language. Ansible is written in Python which is incorporated with most Linux and Unix arrangements, making arrangement simpler and quicker.

Modules :

Puppet's repository is Puppet Forge while Ansible's archive is Ansible Galaxy. Forge is huge (almost 6,000 modules), and the modules can be marked as approved/supported by Puppet, so you won’t have to waste your time on ones that haven’t been proven to work. Galaxy doesn’t have this feature, so you may have to spend some time and effort changing things manually.

Scalability :

Ansible and Puppet both are exceptionally versatile, this implies they could deal with a huge increment in hubs with no issue. Be that as it may, versatility is viewed as progressively advantageous in Ansible.

Support :

Puppet has been around from quite a long time than Ansible and clearly there is more help and greater designer network for the Puppet. You will see dedicated support portal with a knowledge base, and two levels of professional support offered: Standard (included) and Premium. To end up engaged with the Puppet people group, you can get to occasions or take an interest in different channels

Availability :

Both Ansible and Puppet have backups in case of failure. Ansible has a secondary node in case the active node fails, and Puppet has more than one master in case the original master fails.

Graphical User Interface :

Puppet's Graphical User Interface is more interactive than Ansible . You can use it for viewing, managing and monitoring. For more complex tasks, you’ll probably use the command-line interface CLI, which is based on Ruby.

At the hour of its initiation, Ansible will be in order line device as it was before and now you will get a UI if you use the enterprise version, but it’s by no means perfect . Some of the time, GUI isn't in flawless adjust with the Command line and not ready to play out very similar things like the direction lininterface.

Which will be good for use :

Both the tools are brilliant in their own specific manners for various reasons. The correct decision truly descends to your business needs. If you have small and simple organizations Ansible is useful, whereas if you have more complex or longer arrangements Puppet is useful .

In the event, if you have a fixed set of machines to maintain, then Puppet is certainly the best choice. But if your machine count is reprovisioned , Ansible will be the right way to go. The major differences between Ansible and Puppet mean that the right choice really comes down to your organization’s specific needs


Hope you liked it and stay tuned for more updates for the upcoming blogs

Join us on Twitter , Facebook

How to setup Django with Uwsgi and Nginx on Ubuntu 16.04

In this guide we will show you how to setup Django with Uwsgi and Nginx on Ubuntu 16.04. It is difficult and time-consuming to setup your server everytime. As Django is one of the best tools in its field due to its speed, scalability, and security. We thought that being said, we are going to install Django with Uwsgi and Nginx on Ubuntu 16.04 using a few methods and get your server up and running

Prerequisites

• Ubuntu 16.04 server
• Root privileges/ sudo privileges

Ubuntu Repositories :

Login to the server by means of SSH and how about we get all the required stuff introduced:

ssh ubuntu@your-aws-example open ip - I key.pem 

cd ~ 

After login to your server through ssh run the beneath commands:

sudo apt-get update
sudo apt-get install python-dev
sudo apt-get install python-pip

It is a smart thought to work with a virtual domain. To make condition you pursue beneath steps:

mkdir our-projectname
cd our-projectname
pip install virtualenv

We should begin the virtualenv and enter it.

virtualenv venv
source venv/bin/activate

Django packages 

With your virtual condition dynamic, install Django with the local instance of pip by composing

pip install django
django-admin.py startproject project_name

To check if it installed successfully, we have to do a runserver on port 8000

cd project_name
python manage.py runserver 0.0.0.0:8000

Now in the event that you can get to you django undertaking utilizing your server IP, http://IPAddress:8080 your Django project should load up.

Configuring Uwsgi :

Django project keeps running inside the virtualenv. We need Uwsgi to serve django to the web rather than the lightweight improvement server, so we just ran utilizing manage.py runserver command. On the off chance that the idea of running the runserver command on a screen passes your brain, drop it.
Run the underneath command to stop your task and leave the virtualenv

Deactivate your virtualenv:
deactivate

Presently install uwsgi system-wide on the grounds that, we'll be running the server from the root client
sudo pip install uwsgi

Now run your project using uwsgi.  This command does the same thing a manage.py runserver would do

uwsgi --http :8000 --home PATH/TO/THE/VIRTUALENV --chdir 

/PATH/TO/THE/DJANGO/PROJECT/FOLDER/CONTAINING/MANAGE.PY/FILE -w YOUR-PROJECT-NAME.wsgii

Model:

uwsgi - http :8000 - home/home/ubuntu/our-venture/venv - 

chdir/home/ubuntu/our-venture/projectname - w projectname.wsgi 

Presently in the event that you can get to you django undertaking utilizing your server IP, http://IPAddress:8080 your Django task should load up

Presently on the off chance that you can get to you django undertaking utilizing your server IP, http://IPAddress:8080 your Django venture should load up

We have to run this in the 'foundation (run it and screen) so we will accomplish that next
The manner in which we will do it is by utilizing Ubuntu's systemd, which gets pid 1 and this is completely bolstered for variants 15.04 and past. We will give it a chance to initialise our uwsgi procedure.

To store our config alternatives, we have to make an 'ini' document which will contain all the uwsgi config subtleties

sudo mkdir /etc/uwsgi/sites
sudo vim /etc/uwsgi/sites/projectname.ini

We’ll load the file with the config details.
[uwsgi]

          chdir = /home/ubuntu/our-project/hello #same as above
          home = /home/ubuntu/our-project/venv #same as above
          module = hello.wsgi:application #same as above
          master = true
          processes = 5 #more processes, more computing power
          socket = /run/uwsgi/hello.sock #SOCKET_LOC
          chown-socket = ubuntu:www-data #user and user's group
          chmod-socket = 660
          vacuum = true #delete the socket after process ends
          harakiri = 30 #respawn the process if it takes more than 30 secs

save the file

We didn't specify any port like 8000 as we did previously. We will defeat this through an attachment record rather than a port as this is progressively ideal. There is no distinction, just that whatever solicitations were steered to port 8000, would now be required to go by means of the attachment record

Now we can test if this works by running the command:
uwsgi - ini/and so on/uwsgi/locales/projectname.ini

If everything works fine, we can see several lines and status as 5 or some number of procedures have been produced.

we have to let systemd (Ubuntu's administration director) to deal with this:

Ubuntu's SystemD - call-> Service we make - execute-> Uwsgi ini - 
run-> Our Django Project

sudo vim /etc/systemd/system/uwsgi.service

Next you can Paste the following into it

          Description=uWSGI Emperor service
          [Service]
          ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown ubuntu:www-data /run/uwsgi' #make the 
folder where we'll store our socket file and have the right user/group permissions
          ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites #this the command to execute on start
          Restart=always #make sure the server is running
          KillSignal=SIGQUIT
          Type=notify
          NotifyAccess=all
          [Install]
          WantedBy=multi-user.target

Save the file

What we glued is basic, the administration will execute this line everytime it comes up and ensure it is up.

The head mode checks a specific envelope (for our situation, destinations) for .ini records and flames every one of them (our hello.ini is staying there) making it helpful in the event that we have various sites.

/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites

Now let’s tell the systemd to run our service.

sudo systemctl restart uwsgi

If you want to make sure, you could do a top and see the number of processes (search for uwsgi) you wanted to spawn + 1

So now uwsgi is running. But we need to get it to appear when an HTTP request comes in. For that, we’re going to use Nginx.

Let’s install Nginx.

sudo apt-get install nginx
sudo service nginx start

If you hit the http://IPAddress you will see a Nginx welcome page. This is because Nginx is listening to port 80 according to its default configuration

Nginx has two directories, sites-available and sites-enabled. Nginx looks for all conf files in the sites-enabled folder and configures the server according to it.
sudo vim /etc/nginx/sites-available/projectname

You have to paste the following into it.

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com your-ec2-public-ip-address(if you don't have a domain);
    location = /favicon.ico { access_log off; log_not_found off; }
    client_max_body_size 20M;
    client_max_body_size 20M;
    location / {
        include         uwsgi_params;
        uwsgi_pass      unix:/run/uwsgi/hello.sock; #SAME as #SOCKET_LOC in the hello.ini

    }
}

You can let server_name be a subdomain or multiple domains where you want to serve the website. The uwsgi_pass must point to the socket file we had our uwsgi ini file create. You can configure the Nginx conf far more and add a lot of things

We have to add this to sites-enabled directory, in order to be picked up by Nginx.
We can create a symlink to the file.
sudo ln -s /etc/nginx/sites-available/hello /etc/nginx/sites-enabled/

Now restart nginx and you’re all set.

sudo service nginx restart

Domain configuration

This is fairly straightforward. You need to add a simple record to your DNS records

Django configuration

During the configuration you will run into a 400 or 502 errors while trying to serve.
if you’re running with DEBUG = False and have not set ALLOWED_HOSTS in settings.

To allow those domains you have to allow hosts configured. You can allow everything,

ALLOWED_HOST = ['*'] #INCASE you want allow every host but this may turn 
out to be unsafe

Or allow the domains we configured in the nginx conf,

ALLOWED_HOST = ['yourdomain.com','www.yourdomain.com','IPAddress']

Finally, we're live with our django site.

Hope you liked it and if you need any assistance on setting up Django with Uwsgi and Nginx on Ubuntu 16.04. Contact us.

To get glimpses of our activities follow us on: Twitter , Facebook

DirectAdmin or cPanel – Which is better?

DirectAdmin is a web hosting control panel to regulate destinations less difficult with a graphical UI like other online control panels like cPanel, centos web board. Founded in 2003 by JMBC software.  It stays in-adventure with the present most current game plans. The overall examples and clients feature sales are analyzed frequently and the thoughts are brought into practice.
Direct Admin will allow you to administer your site and adjust hosting choices by employing a graphical interface. Therefore this will allow you to manage any amount of sites, basically and in unlimited number. You can also manage email accounts, all whilst utilizing the Direct Admin control board.

Features:

DirectAdmin's web encouraging control board grows incessantly to give clients the latest headways. So go with picked programming and get presented and masterminded normally with the following:

1. Web servers (Apache 2.4, Nginx 1.15, LiteSpeed Web Server, OpenLite Speed)
2. PHP forms with its augmentations (mod_php, PHP-FPM, FastCGI, LSPHP)
3. Database server (MySQL 5.5 to 8.0, MariaDB 5.5/10)
4. Web applications (phpMyAdmin, SquirrelMail, Roundcube)
5. Dovecot IMAP/POP3 Server
6. MTA SMTP server (Exim)
7. Mailing List (Majordomo)
8. FTP Server (ProFTPd, Pure- FTPd)
9. Server Statistics. (AWstats, Webalizer)
10. Antivirus software (ClamAV)
11. Anti-SPAM solutions (SpamAssassin, BlockCracking, Pigeonhole)
12. Application Firewall (ModSecurity)

Here we can examine the distinctions, costs of DirectAdmin and cPanel.

DirectAdmin:

It is one of the easiest control sheets to use and offers access to webmail, chairman options, and your record executive hence essentially more. When you log in, you will see, everything is spread out for on one screen. This makes it easy to find what you're scanning for inside the administrative region.

cPanel:

Freshers will find cPanel easy to investigate and not under any condition like DirectAdmin, cPanel parts the features into classes, which makes them less complex to find. cPanel furthermore gives a greater number of features and modules than DirectAdmin does.
The cPanel has advanced features than DirectAdmin but the price tag is little bit higher than DirectAdmin.

Huge contrasts between these two panels (DirectAdmin and cPanel):

Direct Admin and cPanel are very similar, yet very different. They both offer  server configuration framework and UI, but DirectAdmin leaves quite a bit of the work to be done in the root shell.
cPanel, on the other hand, gives pretty much all the arrangement and handiness inside the UI. This makes it far easier to use and a predominant fit for basically all customer levels.

DirectAdmin is expandable, yet the cost of including additional helpfulness is incredibly high. With cPanel, you can add plugins and modules very easily without much or any added cost. Along with the expandability through modules and plugins, advanced users would custom have the option to code options clearly into the system.

Bottom line : Though both do the same job (hosting account management) by using GUI, users have their likes and dislikes about them.
If you have low configurations server and you have skill, DirectAdmin is good choice but if you are going to use the server to host clients websites, cPanel is good choice. cPanel is more popular for end user and it has easy interface and widely used control panel.

Virtualization Support

DirectAdmin website Link : https://directadmin.com/

Hope this was helpful and if you need any further assistance you can Contact Us.

Follow us on : Twitter , Facebook

Features and Components of Docker in a nutshell!

Today, there is a buzz all around about containerization and Docker, so let's see the features and components of Docker in a nutshell. Docker is an opensource platform for developers and sysadmins to build, ship, and run distributed applications based on Linux containers. It is basically a container engine which uses Linux Kernel features such as namespaces and control groups to create containers on top of an operating system and automate application deployment on the container. It provides a light weight environment to run the application code. Where as Containers allow users to package up an application with all the parts it needs, such as libraries and other dependencies, and ship it all out as one package.

Docker makes sure that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.

Features of Docker

• An isolated, rapid framework.
• An opensource solution
• Cross Cloud infrastructure
• Moderate CPU/memory overhead
• Fast Reboot

Components of Docker in nutshell

Docker is made up of the following major components:

a) Docker Daemon
Docker daemon runs on a host machine. A docker user can not directly interact with the daemon, as the daemon needs the docker client in order to interact.

b) Docker Client

It is the primary user interface to Docker which helps users to interact with the Docker Daemon. It processes the commands from the user and communicates back and forth with a Docker daemon.

c) Docker Images

These are ready-only templates that help launch Docker containers. A docker image can be of CentOS operating system with Apache and your web application installed. These images are used to create the docker containers. Docker allows to build new images or you can simply edit and update the images.

d) Docker Registries

Docker Registries holds the docker images and these registries are either public or private stores from where you upload or download images. The public docker registry provides a huge collection of existing images for use so its also called Docker Hub. You can easily edit and update the images as per your requirements and can upload them to Docker registries.

• When the docker pull or docker run commands, the required images will be pulled from your configured registry.
• when you use the docker push command, your image is pushed to your configured registry.

e) Docker containers

Each Docker container is an isolated & secured application platform which holds everything that is needed for an application to run. You can perform run, start, stop, and migration and delete operations on a Docker container. Docker containers can run on any computer, on any infrastructure, and in any cloud.

Hope Docker in a nutshell was quite helpful to get an idea of what a Docker is and what are its Features and Components.

We offer server administration services with lowest response times at competitive pricing models. You can check out our Server Management plans by using the link below.

Server Management

Read our exciting blog Post: How to install Suhosin under different Linux Distributions