One place for hosting & domains

      Create and Deploy a Docker Container Image to a Kubernetes Cluster

      Updated by Linode Contributed by Linode

      Kubernetes and Docker

      Kubernetes is a system that automates the deployment, scaling, and management of containerized applications. Containerizing an application requires a base image that can be used to create an instance of a container. Once an application’s image exists, you can push it to a centralized container registry that Kubernetes can use to deploy container instances in a cluster’s pods.

      While Kubernetes supports several container runtimes, Docker is a very popular choice. Docker images are created using a Dockerfile that contains all commands, in their required order of execution, needed to build a given image. For example, a Dockerfile might contain instructions to install a specific operating system referencing another image, install an application’s dependencies, and execute configuration commands in the running container.

      Docker Hub is a centralized container image registry that can host your images and make them available for sharing and deployment. You can also find and use official Docker images and vendor specific images. When combined with a remote version control service, like GitHub, Docker Hub allows you to automate building container images and trigger actions for further automation with other services and tooling.

      Scope of This Guide

      This guide will show you how to package a Hugo static site in a Docker container image, host the image on Docker Hub, and deploy the container image on a Kubernetes cluster running on Linode. This example, is meant to demonstrate how applications can be containerized using Docker to leverage the deployment and scaling power of Kubernetes.

      Hugo is written in Go and is known for being extremely fast to compile sites, even very large ones. It is well-supported, well-documented, and has an active community. Some useful Hugo features include shortcodes, which are an easy way to include predefined templates inside of your Markdown, and built-in LiveReload web server, which allows you to preview your site changes locally as you make them.


      This guide was written using version 1.14 of Kubectl.

      Before You Begin

      1. Create a Kubernetes cluster with one worker node. This can be done in two ways:

        1. Deploy a Kubernetes cluster using kubeadm.
          • You will need to deploy two Linodes. One will serve as the master node and the other will serve as a worker node.
        2. Deploy a Kubernetes cluster using k8s-alpha CLI.
      2. Create a GitHub account if you don’t already have one.

      3. Create a Docker Hub account if you don’t already have one.

      Set up the Development Environment

      Development of your Hugo site and Docker image will take place locally on your personal computer. You will need to install Hugo, Docker CE, and Git, a version control software, on your personal computer to get started.

      1. Use the How to Install Git on Linux, Mac or Windows guide for the steps needed to install Git.

      2. Install Hugo. Hugo’s official documentation contains more information on installation methods, like Installing Hugo from Tarball. Below are installation instructions for common operating systems:

        • Debian/Ubuntu:

          sudo apt-get install hugo
        • Fedora, Red Hat and CentOS:

          sudo dnf install hugo
        • Mac, using Homebrew:

          brew install hugo
      3. These steps install Docker Community Edition (CE) using the official Ubuntu repositories. To install on another distribution, see the official installation page.

        1. Remove any older installations of Docker that may be on your system:

          sudo apt remove docker docker-engine
        2. Make sure you have the necessary packages to allow the use of Docker’s repository:

          sudo apt install apt-transport-https ca-certificates curl software-properties-common
        3. Add Docker’s GPG key:

          curl -fsSL | sudo apt-key add -
        4. Verify the fingerprint of the GPG key:

          sudo apt-key fingerprint 0EBFCD88

          You should see output similar to the following:

          pub   4096R/0EBFCD88 2017-02-22
                  Key fingerprint = 9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
          uid                  Docker Release (CE deb) 
          sub   4096R/F273FCD8 2017-02-22
        5. Add the stable Docker repository:

          sudo add-apt-repository "deb [arch=amd64] $(lsb_release -cs) stable"
        6. Update your package index and install Docker CE:

          sudo apt update
          sudo apt install docker-ce
        7. Add your limited Linux user account to the docker group:

          sudo usermod -aG docker $USER


          After entering the usermod command, you will need to close your SSH session and open a new one for this change to take effect.

        8. Check that the installation was successful by running the built-in “Hello World” program:

          docker run hello-world

      Create a Hugo Site

      Initialize the Hugo Site

      In this section you will use the Hugo CLI (command line interface) to create your Hugo site and initialize a Hugo theme. Hugo’s CLI provides several useful commands for common tasks needed to build, configure, and interact with your Hugo site.

      1. Create a new Hugo site on your local computer. This command will create a folder named example-site and scaffold Hugo’s directory structure inside it:

        hugo new site example-site
      2. Move into your Hugo site’s root directory:

        cd example-site
      3. You will use Git to add a theme to your Hugo site’s directory. Initialize your Hugo site’s directory as a Git repository:

        git init
      4. Install the Ananke theme as a submodule of your Hugo site’s Git repository. Git submodules allow one Git repository to be stored as a subdirectory of another Git repository, while still being able to maintain each repository’s version control information separately. The Ananke theme’s repository will be located in the ~/example-site/themes/ananke directory of your Hugo site.

        git submodule add themes/ananke


        Hugo has many available themes that can be installed as a submodule of your Hugo site’s directory.
      5. Add the theme to your Hugo site’s configuration file. The configuration file (config.toml) is located at the root of your Hugo site’s directory.

        echo 'theme = "ananke"' >> config.toml

      Add Content to the Hugo Site

      You can now begin to add content to your Hugo site. In this section you will add a new post to your Hugo site and generate the corresponding static file by building the Hugo site on your local computer.

      1. Create a new content file for your site. This command will generate a Markdown file with an auto-populated date and title:

        hugo new posts/
      2. You should see a similar output. Note that the file is located in the content/posts/ directory of your Hugo site:

        /home/username/example-site/content/posts/ created
      3. Open the Markdown file in the text editor of your choice to begin modifying its content; you can copy and paste the example snippet into your file, which contains an updated front matter section at the top and some example Markdown body text.

        Set your desired value for title. Then, set the draft state to false and add your content below the --- in Markdown syntax, if desired:

        title: "My First Post"
        date: 2019-05-07T11:25:11-04:00
        draft: false
        # Kubernetes Objects
        In Kubernetes, there are a number of objects that are abstractions of your Kubernetes system’s desired state. These objects represent your application, its networking, and disk resources – all of which together form your application. Kubernetes objects can describe:
        - Which containerized applications are running on the cluster
        - Application resources
        - Policies that should be applied to the application

        About front matter

        Front matter is a collection of metadata about your content, and it is embedded at the top of your file within opening and closing --- delimiters.

        Front matter is a powerful Hugo feature that provides a mechanism for passing data that is attached to a specific piece of content to Hugo’s rendering engine. Hugo accepts front matter in TOML, YAML, and JSON formats. In the example snippet, there is YAML front matter for the title, date, and draft state of the Markdown file. These variables will be referenced and displayed by your Hugo theme.

      4. Once you have added your content, you can preview your changes by building and serving the site using Hugo’s built-in webserver:

        hugo server
      5. You will see a similar output:

        &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp| EN
          Pages&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp| 11
          Paginator pages&nbsp&nbsp&nbsp&nbsp|  0
          Non-page files&nbsp&nbsp&nbsp&nbsp&nbsp|  0
          Static files&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  3
          Processed images&nbsp&nbsp&nbsp|  0
          Aliases&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  1
          Sitemaps&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  1
          Cleaned&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|  0
        Total in 7 ms
        Watching for changes in /home/username/example-site/{content,data,layouts,static,themes}
        Watching for config changes in /home/username/example-site/config.toml
        Serving pages from memory
        Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
        Web Server is available at http://localhost:1313/ (bind address
        Press Ctrl+C to stop
      6. The output will provide a URL to preview your site. Copy and paste the URL into a browser to access the site. In the above example Hugo’s web server URL is http://localhost:1313/.

      7. When you are happy with your site’s content you can build the site:

        hugo -v

        Hugo will generate your site’s static HTML files and store them in a public directory that it will create inside your project. The static files that are generated by Hugo are the files that will be served to the internet through your Kubernetes cluster.

      8. View the contents of your site’s public directory:

        ls public

        Your output should resemble the following example. When you built the site, the Markdown file you created and edited in steps 6 and 7 was used to generate its corresponding static HTML file in the public/posts/my-first-post/index.html directory.

          404.html    categories  dist        images      index.html  index.xml   posts       sitemap.xml tags

      Version Control the Site with Git

      The example Hugo site was initialized as a local Git repository in the previous section. You can now version control all content, theme, and configuration files with Git. Once you have used Git to track your local Hugo site files, you can easily push them to a remote Git repository, like GitHub or GitLab. Storing your Hugo site files on a remote Git repository opens up many possibilities for collaboration and automating Docker image builds. This guide will not cover automated builds, but you can learn more about it on Docker’s official documentation.

      1. Add a .gitignore file to your Git repository. Any files or directories added to the .gitignore file will not be tracked by Git. The Docker image you will create in the next section will handle building your static site files. For this reason it is not necessary to track the public directory and its content.

        echo 'public/' >> .gitignore
      2. Display the state of your current working directory (root of your Hugo site):

        git status
      3. Stage all your files to be committed:

        git add -A
      4. Commit all your changes and add a meaningful commit message:

        git commit -m 'Add content, theme, and config files.'


        Any time you complete work related to one logical change to the Hugo site, you should make sure you commit the changes to your Git repository. Keeping your commits attached to small changes makes it easier to understand the changes and to roll back to previous commits, if necessary. See the Getting Started with Git guide for more information.

      Create a Docker Image

      Create the Dockerfile

      A Dockerfile contains the steps needed to build a Docker image. The Docker image provides the minimum set up and configuration necessary to deploy a container that satisfies its specific use case. The Hugo site’s minimum Docker container configuration requirements are an operating system, Hugo, the Hugo site’s content files, and the NGINX web server.

      1. In your Hugo site’s root directory, create and open a file named Dockerfile using the text editor of your choice. Add the following content to the file. You can read the Dockerfile comments to learn what each command will execute in the Docker container.

        #Install the container's OS.
        FROM ubuntu:latest as HUGOINSTALL
        # Install Hugo.
        RUN apt-get update
        RUN apt-get install hugo
        # Copy the contents of the current working directory to the hugo-site
        # directory. The directory will be created if it doesn't exist.
        COPY . /hugo-site
        # Use Hugo to build the static site files.
        RUN hugo -v --source=/hugo-site --destination=/hugo-site/public
        # Install NGINX and deactivate NGINX's default index.html file.
        # Move the static site files to NGINX's html directory.
        # This directory is where the static site files will be served from by NGINX.
        FROM nginx:stable-alpine
        RUN mv /usr/share/nginx/html/index.html /usr/share/nginx/html/old-index.html
        COPY --from=HUGOINSTALL /hugo-site/public/ /usr/share/nginx/html/
        # The container will listen on port 80 using the TCP protocol.
        EXPOSE 80
      2. Add a .dockerignore file to your Hugo repository. It is important to ensure that your images are as small as possible to reduce the time it takes to build, pull, push, and deploy the container. The .dockerignore file excludes files and directories that are not necessary for the function of your container or that may contain sensitive information that you do not want to included in the image. Since the Docker image will build the static Hugo site files, you can ignore the public/ directory. You can also exclude any Git related files and directories because they are not needed on the running container.

        echo -e "public/n.git/n.gitmodules/n.gitignore" >> .dockerignore
      3. Follow the steps 2 – 4 in the Version Control the Site with Git section to add any new files created in this section to your local git repository.

      Build the Docker Image

      You are now ready to build the Docker image. When Docker builds an image it incorporates the build context. A build context includes any files and directories located in the current working directory. By default, Docker assumes the current working directory is also the location of the Dockerfile.


      If you have not yet created a Docker Hub account, you will need to do so before proceeding with this section.
      1. Build the Docker image and add a tag mydockerhubusername/hugo-site:v1 to the image. Ensure you are in the root directory of your Hugo site. The tag will make it easy to reference a specific image version when creating your Kubernetes deployment manifest. Replace mydockerhubusername with your Docker Hub username and hugo-site with a Docker repository name you prefer.

        docker build -t mydockerhubusername/hugo-site:v1 .

        You should see a similar output. The entirety of the output has been removed for brevity:

        Sending build context to Docker daemon  3.307MB
        Step 1/10 : FROM ubuntu:latest as HUGOINSTALL
         ---> 94e814e2efa8
        Step 2/10 : ENV HUGO_VERSION=0.55.4
         ---> Using cache
         ---> e651df397e32
        Successfully built 50c590837916
        Successfully tagged hugo-k8s:v1
      2. View all locally available Docker images:

        docker images

        You should see the docker image hugo-site:v1 listed in the output:

        REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
        hugo-k8s            v1                  50c590837916        1 day ago          16.5MB

      Push your Hugo Site Repository to GitHub

      You can push your local Hugo site’s Git repository to GitHub in order to set up Docker automated builds. Docker automated builds will build an image using a external repository as the build context and automatically push the image to your Docker Hub repository. This step is not necessary to complete this guide.

      Host your Image on Docker Hub

      Hosting your Hugo site’s image on Docker Hub will enable you to use the image in a Kubernetes cluster deployment. You will also be able to share the image with collaborators and the rest of the Docker community.

      1. Log into your Docker Hub account via the command line on your local computer. Enter your username and password when prompted.

        docker login
      2. Push the local Docker image to Docker Hub. Replace mydockerhubusername/hugo-site:v1 with your image’s tag name.

        docker push mydockerhubusername/hugo-site:v1
      3. Navigate to Docker Hub to view your image on your account.

        The url for your image repository should be similar to the following: Replace the username and repository name with your own.

      Configure your Kubernetes Cluster

      This section will use kubectl to configure and manage your Kubernetes cluster. If your cluster was deployed using kubeadm, you will need to log into your master node to execute the kubectl commands in this section. If, instead, you used the k8s-alpha CLI you can run all commands from your local computer.

      In this section, you will create namespace, deployment, and service manifest files for your Hugo site deployment and apply them to your cluster with kubectl. Each manifest file creates different resources on the Kubernetes API that are used to create and the Hugo site’s pods on the worker nodes.

      Create the Namespace

      Namespaces provide a powerful way to logically partition your Kubernetes cluster and isolate components and resources to avoid collisions across the cluster. A common use-case is to encapsulate dev/testing/production environments with namespaces so that they can each utilize the same resource names across each stage of development.

      Namespaces add a layer of complexity to a cluster that may not always be necessary. It is important to keep this in mind when formulating the architecture for a project’s application. This example will create a namespace for demonstration purposes, but it is not a requirement. One situation where a namespace would be beneficial, in the context of this guide, would be if you were a developer and wanted to manage Hugo sites for several clients with a single Kubernetes cluster.

      1. Create a directory to store your Hugo site’s manifest files.

        mkdir -p clientx/k8s-hugo/
      2. Create the manifest file for your Hugo site’s namespace with the following content:

        apiVersion: v1
        kind: Namespace
          name: hugo-site
        • The manifest file declares the version of the API in use, the kind of resource that is being defined, and metadata about the resource. All manifest files should provide this information.
        • The key-value pair name: hugo-site defines the namespace object’s unique name.
      3. Create the namespace from the ns-hugo-site.yaml manifest.

        kubectl create -f clientx/k8s-hugo/ns-hugo-site.yaml
      4. View all available namespaces in your cluster:

        kubectl get namespaces

        You should see the hugo-site namespace listed in the output:

        NAME          STATUS   AGE
        default       Active   1d
        hugo-site     Active   1d
        kube-public   Active   1d
        kube-system   Active   1d

      Create the Service

      The service will group together all pods for the Hugo site, expose the same port on all pods to the internet, and load balance site traffic between all pods. It is best to create a service prior to any controllers (like a deployment) so that the Kubernetes scheduler can distribute the pods for the service as they are created by the controller.

      The Hugo site’s service manifest file will use the NodePort method to get external traffic to the Hugo site service. NodePort opens a specific port on all the Nodes and any traffic that is sent to this port is forwarded to the service. Kubernetes will choose the port to open on the nodes if you do not provide one in your service manifest file. It is recommended to let Kubernetes handle the assignment. Kubernetes will choose a port in the default range, 30000-32767.


      The k8s-alpha CLI creates clusters that are pre-configured with useful Linode service integrations, like the Linode Cloud Controller Manager (CCM) which provides access to Linode’s load balancer service, NodeBalancers. In order to use Linode’s NodeBalancers you can use the LoadBalancer service type instead of NodePort in your Hugo site’s service manifest file. For more details, see the Kubernetes Cloud Controller Manager for Linode GitHub repository.
      1. Create the manifest file for your service with the following content.

        apiVersion: v1
        kind: Service
          name: : hugo-site
          namespace: hugo-site
            app: hugo-site
          - protocol: TCP
            port: 80
            targetPort: 80
          type: NodePort
        • The spec key defines the Hugo site service object’s desired behavior. It will create a service that exposes TCP port 80 on any pod with the app: hugo-site label.
        • The exposed container port is defined by the targetPort:80 key-value pair.
      2. Create the service for your hugo site:

        kubectl create -f clientx/k8s-hugo/service-hugo.yaml
      3. View the service and its corresponding information:

        kubectl get services -n hugo-site

        Your output will resemble the following:

        NAME        TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
        hugo-site   NodePort           80:30304/TCP   1d

      Create the Deployment

      A deployment is a controller that helps manage the state of your pods. The Hugo site deployment will define how many pods should be kept up and running with the Hugo site service and which container image should be used.

      1. Create the manifest file for your Hugo site’s deployment. Copy the following contents to your file.

        apiVersion: apps/v1
        kind: Deployment
          name: hugo-site
          namespace: hugo-site
          replicas: 3
              app: hugo-site
                app: hugo-site
              - name: hugo-site
                image: mydockerhubusername/hugo-site:v1
                imagePullPolicy: Always
                - containerPort: 80
        • The deployment’s object spec states that the deployment should have 3 replica pods. This means at any given time the cluster will have 3 pods that run the Hugo site service.
        • The template field provides all the information needed to create actual pods.
        • The label app: hugo-site helps the deployment know which service pods to target.
        • The container field states that any containers connected to this deployment should use the Hugo site image mydockerhubusername/hugo-site:v1 that was created in the Build the Docker Image section of this guide.
        • imagePullPolicy: Always means that the container image will be pulled every time the pod is started.
        • containerPort: 80 states the port number to expose on the pod’s IP address. The system does not rely on this field to expose the container port, instead, it provides information about the network connections a container uses.
      2. Create the deployment for your hugo site:

        kubectl create -f clientx/k8s-hugo/deployment.yaml
      3. View the Hugo site’s deployment:

        kubectl get deployment hugo-site -n hugo-site

        Your output will resemble the following:

        hugo-site   3/3     3            3           1d

      View the Hugo Site

      After creating all required manifest files to configure your Hugo site’s Kubernetes cluster, you should be able to view the site using a worker node’s IP address and its exposed port.

      1. Get your worker node’s external IP address. Copy down the EXTERNAL-IP value for any worker node in the cluster:

        kubectl get nodes -o wide
      2. Access the hugo-site services to view its exposed port.

        kubectl get svc -n hugo-site

        The output will resemble the following. Copy down the listed port number in the 30000-32767 range.

        NAME        TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
        hugo-site   NodePort           80:30304/TCP   1d
      3. Open a browser window and enter in a worker node’s IP address and exposed port. An example url to your Hugo site would be, Your Hugo site should appear.

        If desired, you can purchase a domain name and use Linode’s DNS Manager to assign a domain name to the cluster’s worker node IP address.

      Tear Down Your Cluster

      To avoid being further billed for your Kubernetes cluster, tear down your cluster’s Linodes. If you have Linodes that existed for only part a monthly billing cycle, you’ll be billed at the hourly rate for that service. See How Hourly Billing Works to learn more.

      Next Steps

      Now that you are familiar with basic Kubernetes concepts, like configuring pods, grouping resources, and deploying services, you can deploy a Kubernetes cluster on Linode for production use by using the steps in the following guides:

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      How To Detect and Extract Faces from an Image with OpenCV and Python

      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.


      Images make up a large amount of the data that gets generated each day, which makes the ability to process these images important. One method of processing images is via face detection. Face detection is a branch of image processing that uses machine learning to detect faces in images.

      A Haar Cascade is an object detection method used to locate an object of interest in images. The algorithm is trained on a large number of positive and negative samples, where positive samples are images that contain the object of interest. Negative samples are images that may contain anything but the desired object. Once trained, the classifier can then locate the object of interest in any new images.

      In this tutorial, you will use a pre-trained Haar Cascade model from OpenCV and Python to detect and extract faces from an image. OpenCV is an open-source programming library that is used to process images.


      Step 1 — Configuring the Local Environment

      Before you begin writing your code, you will first create a workspace to hold the code and install a few dependencies.

      Create a directory for the project with the mkdir command:

      Change into the newly created directory:

      Next, you will create a virtual environment for this project. Virtual environments isolate different projects so that differing dependencies won't cause any disruptions. Create a virtual environment named face_scrapper to use with this project:

      • python3 -m venv face_scrapper

      Activate the isolated environment:

      • source face_scrapper/bin/activate

      You will now see that your prompt is prefixed with the name of your virtual environment:

      Now that you've activated your virtual environment, you will use nano or your favorite text editor to create a requirements.txt file. This file indicates the necessary Python dependencies:

      Next, you need to install three dependencies to complete this tutorial:

      • numpy: numpy is a Python library that adds support for large, multi-dimensional arrays. It also includes a large collection of mathematical functions to operate on the arrays.
      • opencv-utils: This is the extended library for OpenCV that includes helper functions.
      • opencv-python: This is the core OpenCV module that Python uses.

      Add the following dependencies to the file:



      Save and close the file.

      Install the dependencies by passing the requirements.txt file to the Python package manager, pip. The -r flag specifies the location of requirements.txt file.

      • pip install -r requirements.txt

      In this step, you set up a virtual environment for your project and installed the necessary dependencies. You're now ready to start writing the code to detect faces from an input image in next step.

      Step 2 — Writing and Running the Face Detector Script

      In this section, you will write code that will take an image as input and return two things:

      • The number of faces found in the input image.
      • A new image with a rectangular plot around each detected face.

      Start by creating a new file to hold your code:

      In this new file, start writing your code by first importing the necessary libraries. You will import two modules here: cv2 and sys. The cv2 module imports the OpenCV library into the program, and sys imports common Python functions, such as argv, that your code will use.

      import cv2
      import sys

      Next, you will specify that the input image will be passed as an argument to the script at runtime. The Pythonic way of reading the first argument is to assign the value returned by sys.argv[1] function to an variable:

      imagePath = sys.argv[1]

      A common practice in image processing is to first convert the input image to gray scale. This is because detecting luminance, as opposed to color, will generally yield better results in object detection. Add the following code to take an input image as an argument and convert it to grayscale:

      image = cv2.imread(imagePath)
      gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

      The .imread() function takes the input image, which is passed as an argument to the script, and converts it to an OpenCV object. Next, OpenCV's .cvtColor() function converts the input image object to a grayscale object.

      Now that you've added the code to load an image, you will add the code that detects faces in the specified image:

      faceCascade = cv2.CascadeClassifier( + "haarcascade_frontalface_default.xml")
      faces = faceCascade.detectMultiScale(
              minSize=(30, 30)
      print("Found {0} Faces!".format(len(faces)))

      This code will create a faceCascade object that will load the Haar Cascade file with the cv2.CascadeClassifier method. This allows Python and your code to use the Haar Cascade.

      Next, the code applies OpenCV's .detectMultiScale() method on the faceCascade object. This generates a list of rectangles for all of the detected faces in the image. The list of rectangles is a collection of pixel locations from the image, in the form of Rect(x,y,w,h).

      Here is a summary of the other parameters your code uses:

      • gray: This specifies the use of the OpenCV grayscale image object that you loaded earlier.
      • scaleFactor: This parameter specifies the rate to reduce the image size at each image scale. Your model has a fixed scale during training, so input images can be scaled down for improved detection. This process stops after reaching a threshold limit, defined by maxSize and minSize.
      • minNeighbors: This parameter specifies how many neighbors, or detections, each candidate rectangle should have to retain it. A higher value may result in less false positives, but a value too high can eliminate true positives.
      • minSize: This allows you to define the minimum possible object size measured in pixels. Objects smaller than this parameter are ignored.

      After generating a list of rectangles, the faces are then counted with the len function. The number of detected faces are then returned as output after running the script.

      Next, you will use OpenCV's .rectangle() method to draw a rectangle around the detected faces:

      for (x, y, w, h) in faces:
          cv2.rectangle(image, (x, y), (x+w, y+h), (0, 255, 0), 2)

      This code uses a for loop to iterate through the list of pixel locations returned from faceCascade.detectMultiScale method for each detected object. The rectangle method will take four arguments:

      • image tells the code to draw rectangles on the original input image.
      • (x,y), (x+w, y+h) are the four pixel locations for the detected object. rectangle will use these to locate and draw rectangles around the detected objects in the input image.
      • (0, 255, 0) is the color of the shape. This argument gets passed as a tuple for BGR. For example, you would use (255, 0, 0) for blue. We are using green in this case.
      • 2 is the thickness of the line measured in pixels.

      Now that you've added the code to draw the rectangles, use OpenCV's .imwrite() method to write the new image to your local filesystem as faces_detected.jpg. This method will return true if the write was successful and false if it wasn't able to write the new image.

      status = cv2.imwrite('faces_detected.jpg', image)

      Finally, add this code to print the return the true or false status of the .imwrite() function to the console. This will let you know if the write was successful after running the script.

      print ("Image faces_detected.jpg written to filesystem: ",status)

      The completed file will look like this:

      import cv2
      import sys
      imagePath = sys.argv[1]
      image = cv2.imread(imagePath)
      gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
      faceCascade = cv2.CascadeClassifier( + "haarcascade_frontalface_default.xml")
      faces = faceCascade.detectMultiScale(
          minSize=(30, 30)
      print("[INFO] Found {0} Faces!".format(len(faces)))
      for (x, y, w, h) in faces:
          cv2.rectangle(image, (x, y), (x + w, y + h), (0, 255, 0), 2)
      status = cv2.imwrite('faces_detected.jpg', image)
      print("[INFO] Image faces_detected.jpg written to filesystem: ", status)

      Once you've verified that everything is entered correctly, save and close the file.

      Note: This code was sourced from the publicly available OpenCV documentation.

      Your code is complete and you are ready to run the script.

      Step 3 — Running the Script

      In this step, you will use an image to test your script. When you find an image you'd like to use to test, save it in the same directory as your script. This tutorial will use the following image:

      Input Image of four people looking at phones

      If you would like to test with the same image, use the following command to download it:

      • curl -O

      Once you have an image to test the script, run the script and provide the image path as an argument:

      • python path/to/input_image

      Once the script finishes running, you will receive output like this:


      [INFO] Found 4 Faces! [INFO] Image faces_detected.jpg written to filesystem: True

      The true output tells you that the updated image was successfully written to the filesystem. Open the image on your local machine to see the changes on the new file:

      Output Image with detected faces

      You should see that your script detected four faces in the input image and drew rectangles to mark them. In the next step, you will use the pixel locations to extract faces from the image.

      Step 4 — Extracting Faces and Saving them Locally (Optional)

      In the previous step, you wrote code to use OpenCV and a Haar Cascade to detect and draw rectangles around faces in an image. In this section, you will modify your code to extract the detected faces from the image into their own files.

      Start by reopening the file with your text editor:

      Next, add the highlighted lines under the cv2.rectangle line:

      for (x, y, w, h) in faces:
          cv2.rectangle(image, (x, y), (x + w, y + h), (0, 255, 0), 2)
          roi_color = image[y:y + h, x:x + w] 
          print("[INFO] Object found. Saving locally.") 
          cv2.imwrite(str(w) + str(h) + '_faces.jpg', roi_color) 

      The roi_color object plots the pixel locations from the faces list on the original input image. The x, y, h, and w variables are the pixel locations for each of the objects detected from faceCascade.detectMultiScale method. The code then prints output stating that an object was found and will be saved locally.

      Once that is done, the code saves the plot as a new image using the cv2.imwrite method. It appends the width and height of the plot to the name of the image being written to. This will keep the name unique in case there are multiple faces detected.

      The updated script will look like this:

      import cv2
      import sys
      imagePath = sys.argv[1]
      image = cv2.imread(imagePath)
      gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
      faceCascade = cv2.CascadeClassifier( + "haarcascade_frontalface_default.xml")
      faces = faceCascade.detectMultiScale(
          minSize=(30, 30)
      print("[INFO] Found {0} Faces.".format(len(faces)))
      for (x, y, w, h) in faces:
          cv2.rectangle(image, (x, y), (x + w, y + h), (0, 255, 0), 2)
          roi_color = image[y:y + h, x:x + w]
          print("[INFO] Object found. Saving locally.")
          cv2.imwrite(str(w) + str(h) + '_faces.jpg', roi_color)
      status = cv2.imwrite('faces_detected.jpg', image)
      print("[INFO] Image faces_detected.jpg written to filesystem: ", status)

      To summarize, the updated code uses the pixel locations to extract the faces from the image into a new file. Once you have finished updating the code, save and close the file.

      Now that you've updated the code, you are ready to run the script once more:

      • python path/to/image

      You will see the similar output once your script is done processing the image:


      [INFO] Found 4 Faces. [INFO] Object found. Saving locally. [INFO] Object found. Saving locally. [INFO] Object found. Saving locally. [INFO] Object found. Saving locally. [INFO] Image faces_detected.jpg written to file-system: True

      Depending on how many faces are in your sample image, you may see more or less output.

      Looking at the contents of the working directory after the execution of the script, you'll see files for the head shots of all faces found in the input image.

      Directory Listing

      You will now see head shots extracted from the input image collected in the working directory:

      Extracted Faces

      In this step, you modified your script to extract the detected objects from the input image and save them locally.


      In this tutorial, you wrote a script that uses OpenCV and Python to detect, count, and extract faces from an input image. You can update this script to detect different objects by using a different pre-trained Haar Cascade from the OpenCV library, or you can learn how to train your own Haar Cascade.

      Source link

      How To Create an Image of Your Linux Environment and Launch It On DigitalOcean


      DigitalOcean’s Custom Images feature allows you to bring your custom Linux and Unix-like virtual disk images from an on-premise environment or another cloud platform to DigitalOcean and use them to start DigitalOcean Droplets.

      As described in the Custom Images documentation, the following image types are supported natively by the Custom Images upload tool:

      Although ISO format images aren’t officially supported, you can learn how to create and upload a compatible image using VirtualBox by following How to Create a DigitalOcean Droplet from an Ubuntu ISO Format Image.

      If you don’t already have a compatible image to upload to DigitalOcean, you can create and compress a disk image of your Unix-like or Linux system, provided it has the prerequisite software and drivers installed.

      We’ll begin by ensuring that our image meets the Custom Images requirements. To do this, we’ll configure the system and install some software prerequisites. Then, we’ll create the image using the dd command-line utility and compress it using gzip. Following that, we’ll upload this compressed image file to DigitalOcean Spaces, from which we can import it as a Custom Image. Finally, we’ll boot up a Droplet using the uploaded image.


      If possible, you should use one of the DigitalOcean-provided images as a base, or an official distribution-provided cloud image like Ubuntu Cloud. You can then install software and applications on top of this base image to bake a new image, using tools like Packer and VirtualBox. Many cloud providers and virtualization environments also provide tools to export virtual disks to one of the compatible formats listed above, so, if possible, you should use these to simplify the import process. In the cases where you need to manually create a disk image of your system, you can follow the instructions in this guide. Note that these instructions have only been tested with an Ubuntu 18.04 system, and steps may vary depending on your server’s OS and configuration.

      Before you begin with this tutorial, you should have the following available to you:

      • A Linux or Unix-like system that meets all of the requirements listed in the Custom Images product documentation. For example, your boot disk must have:

        • A max size of 100GB
        • An MBR or GPT partition table with a grub bootloader
        • VirtIO drivers installed
      • A non-root user with administrative privileges available to you on the system you’re imaging. To create a new user and grant it administrative privileges on Ubuntu 18.04, follow our Initial Server Setup with Ubuntu 18.04. To learn how to do this on Debian 9, consult Initial Server Setup with Debian 9.

      • An additional storage device used to store the disk image created in this guide, preferably as large as the disk being copied. This can be an attached block storage volume, an external USB drive, an additional physical disk, etc.

      • A DigitalOcean Space and the s3cmd file transfer utility configured for use with your Space. To learn how to create a Space, consult the Spaces Quickstart. To learn how set up s3cmd for use with your Space, consult the s3cmd 2.x Setup Guide.

      Step 1 — Installing Cloud-Init and Enabling SSH

      To begin, we will install the cloud-Init initialization package. Cloud-init is a set of scripts that runs at boot to configure certain cloud instance properties like default locale, hostname, SSH keys and network devices.

      Steps for installing cloud-init will vary depending on the operating system you have installed. In general, the cloud-init package should be available in your OS’s package manager, so if you’re not using a Debian-based distribution, you should substitute apt in the following steps with your distribution-specific package manager command.

      Installing cloud-init

      In this guide, we’ll use an Ubuntu 18.04 server and so will use apt to download and install the cloud-init package. Note that cloud-init may already be installed on your system (some Linux distributions install cloud-init by default). To check, log in to your server and run the following command:

      If you see the following output, cloud-init has already been installed on your server and you can continue on to configuring it for use with DigitalOcean:


      usage: /usr/bin/cloud-init [-h] [--version] [--file FILES] [--debug] [--force] {init,modules,single,query,dhclient-hook,features,analyze,devel,collect-logs,clean,status} ... /usr/bin/cloud-init: error: the following arguments are required: subcommand

      If instead you see the following, you need to install cloud-init:


      cloud-init: command not found

      To install cloud-init, update your package index and then install the package using apt:

      • sudo apt update
      • sudo apt install cloud-init

      Now that we've installed cloud-init, we'll configure it for use with DigitalOcean, ensuring that it uses the ConfigDrive datasource. Cloud-init datasources dictate how cloud-init will search for and update instance configuration and metadata. DigitalOcean Droplets use the ConfigDrive datasource, so we will check that it comes first in the list of datasources that cloud-init searches whenever the Droplet boots.

      Reconfiguring cloud-init

      By default, on Ubuntu 18.04, cloud-init configures itself to use the NoCloud datasource first. This will cause problems when running the image on DigitalOcean, so we need to reconfigure cloud-init to use the ConfigDrive datasource and ensure that cloud-init reruns when the image is launched on DigitalOcean.

      From the command line, navigate to the /etc/cloud/cloud.cfg.d directory:

      • cd /etc/cloud/cloud.cfg.d

      Use the ls command to list the cloud-init config files present in the directory:


      05_logging.cfg 50-curtin-networking.cfg 90_dpkg.cfg curtin-preserve-sources.cfg README

      Depending on your installation, some of these files may not be present. If present, delete the 50-curtin-networking.cfg file, which configures networking interfaces for your Ubuntu server. When the image is launched on DigitalOcean, cloud-init will run and reconfigure these interfaces automatically, so this file is not necessary. If this file is not deleted, the DigitalOcean Droplet created from this Ubuntu image will have its interfaces misconfigured and won't be accessible from the internet:

      • sudo rm 50-curtin-networking.cfg

      Next, we'll run dpkg-reconfigure cloud-init to remove the NoCloud datasource, ensuring that cloud-init searches for and finds the ConfigDrive datasource used on DigitalOcean:

      • sudo dpkg-reconfigure cloud-init

      You should see the following graphical menu:

      Cloud Init dpkg Menu

      The NoCloud datasource is initially highlighted. Press SPACE to unselect it, then hit ENTER.

      Finally, navigate to /etc/netplan:

      Remove the 50-cloud-init.yaml file, which was generated from the cloud-init networking file we removed previously:

      • sudo rm 50-cloud-init.yaml

      The final step is ensuring that we clean up configuration from the initial cloud-init run so that it reruns when the image is launched on DigitalOcean.

      To do this, run cloud-init clean:

      At this point you've installed and configured cloud-init for use with DigitalOcean. You can now move on to enabling SSH access to your droplet.

      Enable SSH Access

      Once you've installed and configured cloud-init, the next step is to ensure that you have a non-root admin user and password available to you on your machine, as outlined in the prerequisites. This step is essential to diagnose any errors that may arise after uploading your image and launching your Droplet. If a preexisting network configuration or bad cloud-init configuration renders your Droplet inaccesible over the network, you can use this user in combination with the DigitalOcean Droplet Console to access your system and diagnose any problems that may have surfaced.

      Once you've set up your non-root administrative user, the final step is to ensure that you have an SSH server installed and running. SSH often comes preinstalled on many popular Linux distributions. The process for checking whether a service is running will vary depending on your server's operating system.. If you aren't sure of how to do this, consult your OS's documentation on managing services. On Ubuntu, you can verify that SSH is up and running using the following command:

      You should see the following output:


      ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2018-10-22 19:59:38 UTC; 8 days 1h ago Docs: man:sshd(8) man:sshd_config(5) Process: 1092 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 1115 (sshd) Tasks: 1 (limit: 4915) Memory: 9.7M CGroup: /system.slice/ssh.service └─1115 /usr/sbin/sshd -D

      If SSH isn't up and running, you can install it using apt (on Debian-based distributions):

      • sudo apt install openssh-server

      By default, the SSH server will start on boot unless configured otherwise. This is desirable when running the system in the cloud, as DigitalOcean can automatically copy in your public key and grant you immediate SSH access to your Droplet after creation.

      Once you've created a non-root administrative user, enabled SSH, and installed cloud-init, you're ready to move on to creating an image of your boot disk.

      Step 2 — Creating Disk Image

      In this step, we'll create a RAW format disk image using the dd command-line utility, and compress it using gzip. We'll then upload the image to DigitalOcean Spaces using s3cmd.

      To begin, log in to your server, and inspect the block device arrangement for your system using lsblk:

      You should see something like the following:


      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 12.7M 1 loop /snap/amazon-ssm-agent/495 loop1 7:1 0 87.9M 1 loop /snap/core/5328 vda 252:0 0 25G 0 disk └─vda1 252:1 0 25G 0 part / vdb 252:16 0 420K 1 disk

      In this case, we notice that our main boot disk is /dev/vda, a 25GB disk, and the primary partition, mounted at /, is /dev/vda1. In most cases the disk containing the partition mounted at / will be the source disk to image. We are going to use dd to create an image of /dev/vda.

      At this point, you should decide where you want to store the disk image. One option is to attach another block storage device, preferably as large as the disk you are going to image. You can then save the image to this attached temporary disk and upload it to DigitalOcean Spaces.

      If you have physical access to the server, you can add an additional drive to the machine or attach another storage device, like an external USB disk.

      Another option, which we'll demonstrate in this guide, is copying the image over SSH to a local machine, from which you can upload it to Spaces.

      No matter which method you choose to follow, ensure that the storage device to which you save the compressed image has enough free space. If the disk you're imaging is mostly empty, you can expect the compressed image file to be significantly smaller than the original disk.

      Warning: Before running the following dd command, ensure that any critical applications have been stopped and your system is as quiet as possible. Copying an actively-used disk may result in some corrupted files, so be sure to halt any data-intensive operations and shut down as many running applications as possible.

      Option 1: Creating Image Locally

      The syntax for the dd command we're going to execute looks as follows:

      • dd if=/dev/vda bs=4M conv=sparse | pv -s 25G | gzip > /mnt/tmp_disk/ubuntu.gz

      In this case, we are selecting /dev/vda as the input disk to image, and setting the input/output block sizes to 4MB (from the default 512 bytes). This generally speeds things up a little bit. In addition, we are using the conv=sparse flag to minimize the output file size by skipping over empty space. To learn more about dd's parameters, consult the dd manpage.

      We then pipe the output to the pv pipe viewer utility so we can visually track the progress of the transfer (this pipe is optional, and requires installing pv using your package manager). If you know the size of the initial disk (in this case it's 25G), you can add the -s 25G to the pv pipe to get an ETA for when the transfer will complete.

      We then pipe it all to gzip, and save it in a file called ubuntu.gz on the temporary block storage volume we've attached to the server. Replace /mnt/tmp_disk with the path to the external storage device you've attached to your server.

      Option 2: Creating Image over SSH

      Instead of provisioning additional storage for your remote machine, you can also execute the copy over SSH if you have enough disk space available on your local machine. Note that depending on the bandwidth available to you, this can be slow and you may incur additional costs for data transfer over the network.

      To copy and compress the disk over SSH, execute the following command on your local machine:

      • ssh remote_user@your_server_ip "sudo dd if=/dev/vda bs=4M conv=sparse | gzip -1 -" | dd of=ubuntu.gz

      In this case, we are SSHing into our remote server, executing the dd command there, and piping the output to gzip. We then transfer the gzip output over the network and save it as ubuntu.gz locally. Ensure you have the dd utility available on your local machine before running this command:



      Create the compressed image file using either of the above methods. This may take several hours, depending on the size of the disk you're imaging and the method you're using to create the image.

      Once you've created the compressed image file, you can move on to uploading it to your DigitalOcean Spaces using s3cmd.

      Step 3 — Uploading Image to Spaces and Custom Images

      As described in the prerequisites, you should have s3cmd installed and configured for use with your DigitalOcean Space on the machine containing your compressed image.

      Locate the compressed image file, and upload it to your Space using s3cmd:

      Note: You should replace your_space_name with your Space’s name and not its URL. For example, if your Space’s URL is, then your Space’s name is example-space-name.

      • s3cmd put /path_to_image/ubuntu.gz s3://your_space_name

      Once the upload completes, navigate to your Space using the DigitalOcean Control Panel, and locate the image in the list of files. We will temporarily make the image publicly accessible so that Custom Images can access it and save a copy.

      At the right-hand side of the image listing, click the More drop down menu, then click into Manage Permissions:

      Spaces Object Configuration

      Then, click the radio button next to Public and hit Update to make the image publicly accessible.

      Warning: Your image will temporarily be publicly accessible to anyone with its Spaces path during this process. If you'd like to avoid making your image temporarily public, you can create your Custom Image using the DigitalOcean API. Be sure to set your image to Private using the above procedure after your image has successfully been transferred to Custom Images.

      Fetch the Spaces URL for your image by hovering over the image name in the Control Panel, and hit Copy URL in the window that pops up.

      Now, navigate to Images in the left hand navigation bar, and then Custom Images.

      From here, upload your image using this URL as detailed in the Custom Images Product Documentation.

      You can then create a Droplet from this image. Note that you need to add an SSH key to the Droplet on creation. To learn how to do this, consult How to Add SSH Keys to Droplets.

      Once your Droplet boots up, if you can SSH into it, you've successfully launched your Custom Image as a DigitalOcean Droplet.


      If you attempt to SSH into your Droplet and are unable to connect, ensure that your image meets the listed requirements and has both cloud-init and SSH installed and properly configured. If you still can't access the Droplet, you can attempt to use the DigitalOcean Droplet Console and the non-root user you created earlier to explore the system and debug your networking, cloud-init and SSH configurations. Another way of debugging your image is to use a virtualization tool like Virtualbox to boot up your disk image inside of a virtual machine, and debug your system's configuration from within the VM.


      In this guide, you've learned how to create a disk image of an Ubuntu 18.04 system using the dd command line utility and upload it to DigitalOcean as a Custom Image from which you can launch Droplets.

      The steps in this guide may vary depending on your operating system, existing hardware, and kernel configuration but, in general, images created from popular Linux distributions should work using this method. Be sure to carefully follow the steps for installing and configuring cloud-init, and ensure that your system meets all the requirements listed in the [prerequisites](todo: link) section above.

      To learn more about Custom Images, consult the offical Custom Images product documentation.

      Source link