One place for hosting & domains

      Ubuntu

      How to Install Mastodon on Ubuntu 16.04


      Updated by Linode Written by Linode

      Use promo code DOCS10 for $10 credit on a new account.

      What is Mastodon?

      Mastodon is a free, decentralized, and open source social network alternative to Twitter. Like Twitter, Mastodon users can follow other users and post messages, images, and videos. Unlike Twitter, there is no single central authority and store for content on the network.

      Instead, anyone can create a Mastodon server, invite friends to join it, and build their own communities. In addition, while each Mastodon instance is privately operated, users from different servers can still communicate with and follow each other across instances.

      The Fediverse

      The grouping of all the independent social network servers is referred to as the Fediverse. Mastodon can communicate with any server implementing the ActivityPub and/or OStatus protocols (one other example is GNU Social), and Mastodon is just one implementation of these protocols.

      While Mastodon servers are privately-operated, they are often open to public registration. Some servers are small, and some are very large (for example, Mastodon.social has over 180,000 users). Servers are frequently centered on specific interests of their users, or by the principles those users have defined. To enforce those principles, each Mastodon server has the power to moderate and set rules for the content created by the users on that server (for example, see Mastodon.social’s Code of Conduct).

      Before You Begin

      This guide will create a Mastodon server on a Linode running Ubuntu 16.04. Docker Compose is used to install Mastodon. If you prefer a different Linux distribution, you may be able to use this guide with small changes to the listed commands.

      1. Familiarize yourself with Linode’s Getting Started guide and complete the steps for deploying and setting up a Linode, including setting the hostname and timezone.

        Note

      2. This guide uses sudo wherever possible. Complete the sections of our Securing Your Server guide to create a standard user account, harden SSH access and remove unnecessary network services.

      3. Replace each instance of example.com in this guide with your Mastodon site’s domain name.

      4. Complete the Add DNS Records steps to register a domain name that will point to your Mastodon Linode.

      5. Ensure your system is up to date:

        sudo apt update && sudo apt upgrade
        
      6. Mastodon will serve its content over HTTPS, so you will need to obtain an SSL/TLS certificate. Request and download a free certificate from Let’s Encrypt using Certbot:

        sudo apt install software-properties-common
        sudo add-apt-repository ppa:certbot/certbot
        sudo apt update
        sudo apt install certbot
        sudo certbot certonly --standalone -d example.com
        

        These commands will download a certificate to /etc/letsencrypt/live/example.com/ on your Linode.

        Why not use the Docker Certbot image?

        When Certbot is run, you generally pass a command with the --deploy-hook option which reloads your web server. In your deployment, the web server will run in its own container, and the Certbot container would not be able to directly reload it. Another workaround would be needed to enable this architecture.
      7. Mastodon sends email notifications to users for different events, like when a user first signs up, or when someone else requests to follow them. You will need to supply an SMTP server which will be used to send these messages.

        One option is to install your own mail server using the Email with Postfix, Dovecot, and MySQL guide. You can install such a mail server on the same Linode as your Mastodon server, or on a different one. If you follow this guide, be sure to create a [email protected] email address which you will later use for notifications. If you install your mail server on the same Linode as your Mastodon deployment, you can use your Let’s Encrypt certificate in /etc/letsencrypt/live/example.com/ for the mail server too.

        If you would rather not self-host an email server, you can use a third-party SMTP service. The instructions in this guide will also include settings for using Mailgun as your SMTP provider.

      8. This guide uses Mastodon’s Docker Compose deployment method. Before proceeding, install Docker and Docker Compose. If you haven’t used Docker before, it’s recommended that you review the Introduction to Docker and How to Use Docker Compose guides.

      Install Docker

      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 docker.io
        
      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 https://download.docker.com/linux/ubuntu/gpg | 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) <[email protected]>
        sub   4096R/F273FCD8 2017-02-22
        
      5. Add the stable Docker repository:

        sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(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 exampleuser
        

        You will need to restart your shell session 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
        

      Install Docker Compose

      1. Download the latest version of Docker Compose. Check the releases page and replace 1.21.2 in the command below with the version tagged as Latest release:

        sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
        
      2. Set file permissions:

        sudo chmod +x /usr/local/bin/docker-compose
        

      Set Up Mastodon

      Mastodon has a number of components: PostgreSQL and Redis are used to store data, and three different Ruby on Rails services are used to power the web application. These are all combined in a Docker Compose file that Mastodon provides.

      Download Mastodon and Configure Docker Compose

      1. SSH into your Linode and clone Mastodon’s Git repository:

        cd ~/
        git clone https://github.com/tootsuite/mastodon
        cd mastodon
        
      2. The Git repository includes an example docker-compose.yml which needs some updates to be used in your deployment. The first update you will make is to specify a release of the Mastodon Docker image. The Mastodon GitHub page maintains a chronological list of releases, and you should generally choose the latest version available.

        Open docker-compose.yml in your favorite text editor, comment-out the build lines, and add a version number to the image lines for the web, streaming, and sidekiq services:

        docker-compose.yml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        
        version: '3'
        
        services:
          # [...]
        
          web:
        #    build: .
            image: tootsuite/mastodon:v2.4.2
            # [...]
        
          streaming:
        #    build: .
            image: tootsuite/mastodon:v2.4.2
            # [...]
        
          sidekiq:
        #    build: .
            image: tootsuite/mastodon:v2.4.2
            # [...]

        Note

      3. For the db, redis, web, and sidekiq services, set the volumes listed in this snippet:

        docker-compose.yml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        
        version: '3'
        
        services:
          db:
            # [...]
            volumes:
              - ./postgres:/var/lib/postgresql/data
        
          redis:
            # [...]
            volumes:
              - ./redis:/data
        
          web:
            # [...]
            volumes:
              - ./public/system:/mastodon/public/system
              - ./public/assets:/mastodon/public/assets
              - ./public/packs:/mastodon/public/packs
        
          sidekiq:
            # [...]
            volumes:
              - ./public/system:/mastodon/public/system
              - ./public/packs:/mastodon/public/packs
      4. After the sidekiq service and before the final networks section, add a new nginx service. NGINX will be used to proxy requests on HTTP and HTTPS to the Mastodon Ruby on Rails application:

        docker-compose.yml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        
        version: '3'
        
        services:
          # [...]
        
          sidekiq:
            # [...]
        
          nginx:
            build:
              context: ./nginx
              dockerfile: Dockerfile
            ports:
              - "80:80"
              - "443:443"
            volumes:
               - /etc/letsencrypt/:/etc/letsencrypt/
               - ./public/:/home/mastodon/live/public
               - /usr/share/nginx/html:/usr/share/nginx/html
            restart: always
            depends_on:
              - web
              - streaming
            networks:
              - external_network
              - internal_network
        
        networks:
          # [...]
          st
      5. Compare your edited docker-compose.yml with this copy of the complete file and make sure all the necessary changes were included.

      6. Create a new nginx directory within the Mastodon Git repository:

        mkdir nginx
        
      7. Create a file named Dockerfile in the nginx directory and paste in the following contents:

        nginx/Dockerfile
        1
        2
        3
        
        FROM nginx:latest
        
        COPY default.conf /etc/nginx/conf.d
      8. Create a file named default.conf in the nginx directory and paste in the following contents. Change each instance of example.com:

        nginx/default.conf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        44
        45
        46
        47
        48
        49
        50
        51
        52
        53
        54
        55
        56
        57
        58
        59
        60
        61
        62
        63
        64
        65
        66
        67
        68
        69
        70
        71
        72
        73
        74
        75
        76
        77
        78
        79
        80
        81
        82
        83
        84
        85
        86
        87
        88
        89
        90
        
        map $http_upgrade $connection_upgrade {
          default upgrade;
          ''      close;
        }
        
        server {
          listen 80;
          listen [::]:80;
          server_name example.com;
          # Useful for Let's Encrypt
          location /.well-known/acme-challenge/ { root /usr/share/nginx/html; allow all; }
          location / { return 301 https://$host$request_uri; }
        }
        
        server {
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          server_name example.com;
        
          ssl_protocols TLSv1.2;
          ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
          ssl_prefer_server_ciphers on;
          ssl_session_cache shared:SSL:10m;
        
          ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        
          keepalive_timeout    70;
          sendfile             on;
          client_max_body_size 0;
        
          root /home/mastodon/live/public;
        
          gzip on;
          gzip_disable "msie6";
          gzip_vary on;
          gzip_proxied any;
          gzip_comp_level 6;
          gzip_buffers 16 8k;
          gzip_http_version 1.1;
          gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
        
          add_header Strict-Transport-Security "max-age=31536000";
        
          location / {
            try_files $uri @proxy;
          }
        
          location ~ ^/(packs|system/media_attachments/files|system/accounts/avatars) {
            add_header Cache-Control "public, max-age=31536000, immutable";
            try_files $uri @proxy;
          }
        
          location @proxy {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header Proxy "";
            proxy_pass_header Server;
        
            proxy_pass http://web:3000;
            proxy_buffering off;
            proxy_redirect off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        
            tcp_nodelay on;
          }
        
          location /api/v1/streaming {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header Proxy "";
        
            proxy_pass http://streaming:4000;
            proxy_buffering off;
            proxy_redirect off;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        
            tcp_nodelay on;
          }
        
          error_page 500 501 502 503 504 /500.html;
        }

      Configure Mastodon

      The configuration settings for Mastodon are held in the .env.production file at the root of the Mastodon Git repository.

      1. Create the .env.production file and copy in the following contents. Replace all instances of example.com with your domain name. Fill in the SMTP_SERVER and SMTP_PASSWORD fields with the domain and credentials from your mail server:

        .env.production
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        
        LOCAL_DOMAIN=example.com
        SINGLE_USER_MODE=false
        SECRET_KEY_BASE=
        OTP_SECRET=
        VAPID_PRIVATE_KEY=
        VAPID_PUBLIC_KEY=
        
        # Database settings
        DB_HOST=db
        DB_PORT=5432
        DB_NAME=postgres
        DB_USER=postgres
        DB_PASS=
        
        # Redis settings
        REDIS_HOST=redis
        REDIS_PORT=6379
        REDIS_PASSWORD=
        
        # Mail settings
        SMTP_SERVER=your_smtp_server_domain_name
        SMTP_PORT=587
        SMTP_LOGIN=[email protected]
        SMTP_PASSWORD=your_smtp_password
        SMTP_AUTH_METHOD=plain
        SMTP_OPENSSL_VERIFY_MODE=none
        SMTP_FROM_ADDRESS=Mastodon <[email protected]>

        If you’re using Mailgun for your mail service, remove all the lines from the Mail settings section and enter the following options:

        .env.production
        1
        2
        3
        4
        
        SMTP_SERVER=smtp.mailgun.org
        SMTP_PORT=587
        SMTP_LOGIN=your_mailgun_email
        SMTP_PASSWORD=your_mailgun_email_password
      2. Use Docker and Mastodon to generate a new value for the SECRET_KEY_BASE setting:

        SECRET_KEY_BASE=$(docker-compose run --rm web bundle exec rake secret)
        

        This creates a string of random characters. If you encounter an error in the next step, run the command again to generate another string.

      3. Insert the SECRET_KEY_BASE setting into .env.production using the sed command:

        sed -i -e "s/SECRET_KEY_BASE=/&${SECRET_KEY_BASE}/" .env.production
        
      4. Combine the previous two actions into one step to set a value for the OTP_SECRET setting in .env.production:

        sed -i "s/OTP_SECRET=$/&$(docker-compose run --rm web bundle exec rake secret)/" .env.production
        
      5. Generate values for VAPID_PRIVATE_KEY and VAPID_PUBLIC_KEYsettings:

        docker-compose run --rm web bundle exec rake mastodon:webpush:generate_vapid_key
        
      6. Copy the output from the previous command, open .env.production in your text editor, and paste the command output into the two lines for VAPID_PRIVATE_KEY and VAPID_PUBLIC_KEY.

      7. Build the Docker Compose file:

        docker-compose build
        

      Complete the Mastodon Setup

      1. Set Mastodon as the owner of the public directory inside the Mastodon Git repository:

        sudo chown -R 991:991 public
        

        Note

        The UID that Mastodon will run under is 991, but there is no mastodon user created on your system.

      2. Create a directory which will hold Let’s Encrypt challenge files for future certificate renewals:

        sudo mkdir -p /usr/share/nginx/html
        
      3. Set up the database:

        docker-compose run --rm web bundle exec rake db:migrate
        
      4. Pre-compile Mastodon’s assets:

        docker-compose run --rm web bundle exec rake assets:precompile
        

        This command will take a while to complete.

      5. Start Mastodon:

        docker-compose up -d
        

      Create your Mastodon User

      1. Visit your domain in a web browser:

        Mastodon Sign Up Screen

      2. Enter a new username, email address, and password to create a new user on your Mastodon instance. When communicating with users of other Mastodon servers, your full username is @[email protected].

      3. Mastodon will attempt to send you a confirmation email. Check your email and click the provided link to confirm your registration.

        If you did not set up email notifications, you can manually confirm the new user by running the confirm_email task on the Docker container:

        docker-compose run web bundle exec rake mastodon:confirm_email USER_EMAIL=your_email_address
        
      4. Run the make_admin task on your Docker container to make this new user an admin for the Mastodon instance:

        docker-compose run web bundle exec rake mastodon:make_admin USERNAME=your_mastodon_instance_user
        

      Troubleshooting

      If your Mastodon site doesn’t load in your browser, try reviewing the logs generated by Docker for more information. To see these errors:

      1. Shut down your containers:

        cd mastodon
        docker-compose down
        
      2. Run Docker Compose in an attached state so that you can view the logs generated by each container:

        docker-compose up
        
      3. To shut down Docker Compose and return to the command prompt again, enter CTRL-C.

      If your Mastodon site appears, but some specific site functions are not working, use the tools available in Mastodon’s administrative settings, found through example.com/admin/settings/edit. The Sidekiq dashboard displays the status of jobs issued by Mastodon:

      Sidekiq Dashboard

      Maintenance

      To update your Mastodon version, review the instructions from the Mastodon GitHub’s Docker Guide. You should also review the Mastodon release notes.

      Renew your Let’s Encrypt Certificate

      1. Open your Crontab in your editor:

        sudo crontab -e
        
      2. Add a line which will invoke Certbot at 11PM every day. Replace example.com with your domain:

        0 23 * * *   certbot certonly -n --webroot -w /usr/share/nginx/html -d example.com --deploy-hook='docker exec mastodon_nginx_1 nginx -s reload'
        
      3. You can test your new job with the --dry-run option:

        sudo bash -c "certbot certonly -n --webroot -w /usr/share/nginx/html -d example.com --deploy-hook='docker exec mastodon_nginx_1 nginx -s reload' --dry-run"
        

      Using your New Mastodon Instance

      Now that your new instance is running, you can start participating in the Mastodon network. The official Mastodon User’s Guide describes the mechanics of the application and network. Mastodon’s founder, Eugen Rochko, has also written a non-technical blog post that outlines his best practices for building a new community: How to start a Mastodon server.

      Mastodon’s discussion forum hosts conversations about technical issues and governance/community concerns. Mastodon’s official blog highlights new releases and features articles on the philosophy of Mastodon’s design.

      To add your new instance to the list at joinmastodon.org, submit it through instances.social.

      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.

      Join our Community

      Find answers, ask questions, and help others.

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



      Source link

      How to Install Ghost CMS with Docker Compose on Ubuntu 18.04


      Updated by Linode

      Written by Linode


      Use promo code DOCS10 for $10 credit on a new account.

      Ghost is an open source blogging platform that helps you easily create a professional-looking online blog.

      Ghost’s 1.0.0 version was the first major, stable release of the Ghost content management system (CMS). Ghost includes a Markdown editor, refreshed user interface, new default theme design, and more. Ghost has been frequently updated since this major release, and the current version at time of publication is 1.25.5.

      In this guide you’ll deploy Ghost using Docker Compose on Ubuntu 18.04. Ghost is powered by JavaScript and Node.js. Using Docker to deploy Ghost will encapsulate all of Ghost’s Node dependencies and keep the deployment self-contained. The Docker Compose services are also fast to set up and easy to update.

      Before you Begin

      1. Familiarize yourself with Linode’s Getting Started guide and complete the steps for deploying and setting up a Linode running Ubuntu 18.04, including setting the hostname and timezone.

      2. This guide uses sudo wherever possible. Complete the sections of our Securing Your Server guide to create a standard user account, harden SSH access and remove unnecessary network services.

        Note

        Replace each instance of example.com in this guide with your Ghost site’s domain name.

      3. Complete the Add DNS Records steps to register a domain name that will point to your Ghost Linode.

      4. Ensure your system is up to date:

        sudo apt update && sudo apt upgrade
        
      5. Your Ghost site will serve its content over HTTPS, so you will need to obtain an SSL/TLS certificate. Use Certbot to request and download a free certificate from Let’s Encrypt:

        sudo apt install software-properties-common
        sudo add-apt-repository ppa:certbot/certbot
        sudo apt update
        sudo apt install certbot
        sudo certbot certonly --standalone -d example.com
        

        These commands will download a certificate to /etc/letsencrypt/live/example.com/ on your Linode.


        Why not use Certbot’s Docker container?

        When your certificate is periodically renewed, your web server needs to be reloaded in order to use the new certificate. This is usually accomplished by passing a web server reload command through Certbot’s --deploy-hook option.

        In your deployment, the web server will run in its own container, and the Certbot container would not be able to directly reload it. A workaround for this limitation would be needed to enable this architecture.

      6. Install Docker and Docker Compose before proceeding. If you haven’t used Docker before, review the Introduction to Docker, When and Why to Use Docker, and How to Use Docker Compose guides for some context on how these technologies work.

      Install Docker

      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 docker.io
        
      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 https://download.docker.com/linux/ubuntu/gpg | 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) <[email protected]>
        sub   4096R/F273FCD8 2017-02-22
        
      5. Add the stable Docker repository:

        sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(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 exampleuser
        

        You will need to restart your shell session 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
        

      Install Docker Compose

      1. Download the latest version of Docker Compose. Check the releases page and replace 1.21.2 in the command below with the version tagged as Latest release:

        sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
        
      2. Set file permissions:

        sudo chmod +x /usr/local/bin/docker-compose
        

      Install Ghost

      The Ghost deployment has three components:

      • The Ghost service itself;
      • A database (MySQL) that will store your blog posts;
      • A web server (NGINX) that will proxy requests on HTTP and HTTPS to your Ghost service.

      These services are listed in a single Docker Compose file.

      Create the Docker Compose file

      1. Create and change to a directory to hold your new Docker Compose services:

        mkdir ghost && cd ghost
        
      2. Create a file named docker-compose.yml and open it in your text editor. Paste in the contents from the following snippet. Replace example.com with your domain, and insert a new database password where your_database_root_password appears. The values for database__connection__password and MYSQL_ROOT_PASSWORD should be the same:

        docker-compose.yml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        
        version: '3'
        services:
        
          ghost:
            image: ghost:latest
            restart: always
            depends_on:
              - db
            environment:
              url: https://example.com
              database__client: mysql
              database__connection__host: db
              database__connection__user: root
              database__connection__password: your_database_root_password
              database__connection__database: ghost
            volumes:
              - /opt/ghost_content:/var/lib/ghost/content
        
          db:
            image: mysql:5.7
            restart: always
            environment:
              MYSQL_ROOT_PASSWORD: your_database_root_password
            volumes:
              - /opt/ghost_mysql:/var/lib/mysql
        
          nginx:
            build:
              context: ./nginx
              dockerfile: Dockerfile
            restart: always
            depends_on:
              - ghost
            ports:
              - "80:80"
              - "443:443"
            volumes:
               - /etc/letsencrypt/:/etc/letsencrypt/
               - /usr/share/nginx/html:/usr/share/nginx/html
      3. The Docker Compose file creates a few Docker bind mounts:

        • /var/lib/ghost/content and /var/lib/mysql inside your containers are mapped to /opt/ghost_content and /opt/ghost_mysql on the Linode. These locations store your Ghost content.

        • NGINX uses a bind mount for /etc/letsencrypt/ to access your Let’s Encrypt certificates.

        • NGINX also uses a bind mount for /usr/share/nginx/html so that it can access the Let’s Encrypt challenge files that are created when your certificate is renewed.

        Create directories for those bind mounts (except for /etc/letsencrypt/, which was already created when you first generated your certificate):

        sudo mkdir /opt/ghost_content
        sudo mkdir /opt/ghost_mysql
        sudo mkdir -p /usr/share/nginx/html
        

      Create the NGINX Docker Image

      The Docker Compose file relies on a customized NGINX image. This image will be packaged with the appropriate server block settings.

      1. Create a new nginx directory for this image:

        mkdir nginx
        
      2. Create a file named Dockerfile in the nginx directory and paste in the following contents:

        nginx/Dockerfile
        1
        2
        3
        
        FROM nginx:latest
        
        COPY default.conf /etc/nginx/conf.d
      3. Create a file named default.conf in the nginx directory and paste in the following contents. Replace all instances of example.com with your domain:

        nginx/default.conf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        
        server {
          listen 80;
          listen [::]:80;
          server_name example.com;
          # Useful for Let's Encrypt
          location /.well-known/acme-challenge/ { root /usr/share/nginx/html; allow all; }
          location / { return 301 https://$host$request_uri; }
        }
        
        server {
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          server_name example.com;
        
          ssl_protocols TLSv1.2;
          ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
          ssl_prefer_server_ciphers on;
          ssl_session_cache shared:SSL:10m;
        
          ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        
          location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Proto https;
            proxy_pass http://ghost:2368;
          }
        }

        This configuration will redirect all requests on HTTP to HTTPS (except for Let’s Encrypt challenge requests), and all requests on HTTPS will be proxied to the Ghost service.

      Run and Test Your Site

      From the ghost directory start the Ghost CMS by running all services defined in the docker-compose.yml file:

      docker-compose up -d
      

      Verify that your blog appears by loading your domain in a web browser. It may take a few minutes for Docker to start your services, so try refreshing if the page does not appear when you first load it.

      If your site doesn’t appear in your browser, review the logs generated by Docker for more information. To see these errors:

      1. Shut down your containers:

        cd ghost
        docker-compose down
        
      2. Run Docker Compose in an attached state so that you can view the logs generated by each container:

        docker-compose up
        
      3. To shut down your services and return the command prompt again, press CTRL-C.

      Complete the Setup

      To complete the setup process, navigate to the Ghost configuration page by appending /ghost to the end of your blog’s URL or IP. This example uses https://example.com/ghost.

      1. On the welcome screen, click Create your account:

        Ghost Welcome Screen

      2. Enter your email, create a user and password, and enter a blog title:

        Create Your Account Screen

      3. Invite additional members to your team. If you’d prefer to skip this step, click I’ll do this later, take me to my blog! at the bottom of the page:

        Invite Your Team Screen

      4. Navigate to the Ghost admin area to create your first post, change your site’s theme, or configure additional settings:

        Ghost Admin Area

      Usage and Maintenance

      Because the option restart: always was assigned to your services in your docker-compose.yml file, you do not need to manually start your containers if you reboot your Linode. This option tells Docker Compose to automatically start your services when the server boots.

      Update Ghost

      Your docker-compose.yml specifies the latest version of the Ghost image, so it’s easy to update your Ghost version:

      docker-compose down
      docker-compose pull && docker-compose up -d
      

      Renew your Let’s Encrypt Certificate

      1. Open your Crontab in your editor:

        sudo crontab -e
        
      2. Add a line which will automatically invoke Certbot at 11PM every day. Replace example.com with your domain:

        0 23 * * *   certbot certonly -n --webroot -w /usr/share/nginx/html -d example.com --deploy-hook='docker exec ghost_nginx_1 nginx -s reload'
        

        Certbot will only renew your certificate if its expiration date is within 30 days. Running this every night ensures that if something goes wrong at first, the script will have a number of chances to try again before the expiration.

      3. You can test your new job with the --dry-run option:

        sudo bash -c "certbot certonly -n --webroot -w /usr/share/nginx/html -d example.com --deploy-hook='docker exec ghost_nginx_1 nginx -s reload'"
        

      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.

      Join our Community

      Find answers, ask questions, and help others.

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



      Source link

      Use Buildbot for Software Testing on Ubuntu 18.04


      Updated by Linode Written by Tyler Langlois

      Use promo code DOCS10 for $10 credit on a new account.

      Buildbot is an open source system for testing software projects. In this guide, you will set up a Linode as a Buildbot server to use as a continuous integration platform to test code. Similarly to hosted solutions like Travis CI, Buildbot is an automated testing platform that can watch for code changes, test a project’s code, and send notifications regarding build failures.

      Before you Begin

      1. Familiarize yourself with Linode’s Getting Started guide and complete the steps for deploying and setting up a Linode running Ubuntu 18.04, including setting the hostname and timezone.

      2. This guide uses sudo wherever possible. Complete the sections of our Securing Your Server guide to create a standard user account, harden SSH access and remove unnecessary network services.

      3. Ensure your system is up to date:

        sudo apt update && sudo apt upgrade
        
      4. Complete the Add DNS Records steps to register a domain name that will point to your Linode instance hosting Buildbot.

        Note

        Replace each instance of example.com in this guide with your Buildbot site’s domain name.

      5. Your Buildbot site will serve its content over HTTPS, so you will need to obtain an SSL/TLS certificate. Use Certbot to request and download a free certificate from Let’s Encrypt.

        sudo apt install software-properties-common
        sudo add-apt-repository ppa:certbot/certbot
        sudo apt update
        sudo apt install certbot
        sudo certbot certonly --standalone -d example.com
        

        These commands will download a certificate to /etc/letsencrypt/live/example.com/ on your Linode.

        Note

      Install Buildbot

      Install the Buildbot Master

      Since Buildbot is provided as an Ubuntu package, install the software from the official Ubuntu repositories.

      1. Install the buildbot package along with pip3, which will be used to install additional python packages:

        sudo apt-get install -y buildbot python3-pip
        
      2. Install the required Buildbot Python packages:

        sudo pip3 install buildbot-www buildbot-waterfall-view buildbot-console-view buildbot-grid-view
        
      3. The buildbot package sets up several file paths and services to run persistently on your host. In order to create a new configuration for a Buildbot master, enter the directory for Buildbot master configurations and create a new master called ci (for “continuous integration”).

        cd /var/lib/buildbot/masters
        sudo -u buildbot -- buildbot create-master ci
        

        The generated master configuration file’s location is /var/lib/buildbot/masters/ci/master.cfg.sample.

      4. Make a copy of the default configuration to the path that Buildbot expects for its configuration file:

        sudo cp ci/master.cfg.sample ci/master.cfg
        
      5. Change the permissions for this configuration file so that the buildbot user has rights for the configuration file:

        sudo chown buildbot:buildbot ci/master.cfg
        

      Configure the Buildbot Master

      In order to secure and customize Buildbot, you will change a few settings in the master configuration file before using the application. The master configuration file’s location is /var/lib/buildbot/masters/ci/master.cfg.

      Buildbot has a number of concepts that are represented in the master build configuration file. Open this file in your preferred text editor and browse the Buildbot configuration. The Buildbot configuration is written in Python instead of a markup language like Yaml.

      1. Generate a random string to serve as the password that workers will use to authenticate against the Buildbot master. This is accomplished by using openssl to create a random sequence of characters.

        openssl rand -hex 16
        <a random string>
        
      2. Update the following line in the master.cfg file and replace pass with the randomly-generated password:

        /var/lib/buildbot/masters/ci/master.cfg
        1
        2
        3
        4
        5
        6
        7
        
        ...
        # The 'workers' list defines the set of recognized workers. Each element is
        # a Worker object, specifying a unique worker name and password.  The same
        # worker name and password must be configured on the worker.
        c['workers'] = [worker.Worker("example-worker", "pass")]
        ...
            
      3. Uncomment the cUse Buildbot for Software Testing on Ubuntu 18.04 and the c[titleURL] lines. If desired, change the name of the Buildbot installation by updating the value of cUse Buildbot for Software Testing on Ubuntu 18.04. Replace the c[titleURL] value with the URL of your Buildbot instance. In the example, the URL value is replaced with example.com.

        /var/lib/buildbot/masters/ci/master.cfg
        1
        2
        3
        4
        5
        
        ...
        c['title'] = "My CI"
        c['titleURL'] = "https://example.com"
        ...
            
      4. Uncomment the c['buildbotURL'] line and replace the URL value with the your Buildbot instance’s URL:

        /var/lib/buildbot/masters/ci/master.cfg
        1
        2
        3
        4
        
        ...
        c['buildbotURL'] = "https://example.com/"
        ...
            

        These options assume that you will use a custom domain secured with Let’s Encrypt certificates from certbot as outlined in the Before You Begin section of this guide.

      5. Uncomment the web interface configuration lines and keep the default options:

        /var/lib/buildbot/masters/ci/master.cfg
        1
        2
        3
        4
        5
        
        ...
        c['www'] = dict(port=8010,
                        plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
        ...
            
      6. By default, Buildbot does not require people to authenticate in order to access control features in the web UI. To secure Buildbot, you will need to configure an authentication plugin.

        Configure users for the Buildbot master web interface. Add the following lines below the web interface configuration lines and replace the myusername and password values with the ones you would like to use.

        /var/lib/buildbot/masters/ci/master.cfg
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        
        ...
        c['www'] = dict(port=8010,
                        plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
        
        # user configurations
        c['www']['authz'] = util.Authz(
                allowRules = [
                    util.AnyEndpointMatcher(role="admins")
                ],
                roleMatchers = [
                    util.RolesFromUsername(roles=['admins'], usernames=['myusername'])
                ]
        )
        c['www']['auth'] = util.UserPasswordAuth([('myusername','password')])
        ...
            
      7. Buildbot supports building repositories based on GitHub activity. This is done with a GitHub webhook. Generate a random string to serve as a webhook secret token to validate payloads.

        openssl rand -hex 16
        <a random string>
        
      8. Configure Buildbot to recognize GitHub webhooks as a change source. Add the following snippet to the end of the master.cfg file and replace webhook secret with the random string generated in the previous step.

        /var/lib/buildbot/masters/ci/master.cfg
        1
        2
        3
        4
        5
        6
        
        c['www']['change_hook_dialects'] = {
            'github': {
                'secret': 'webhook_secret',
            }
        }
            
      9. Finally, start the Buildbot master. This command will start the Buildbot process and persist it across reboots.

        sudo systemctl enable --now [email protected]
        

      Set up the Buildbot Master Web Interface

      Buildbot is now running and listening on HTTP without encryption. To secure the connection, install NGINX to terminate SSL and reverse proxy traffic to the Buildbot master process.

      These steps install NGINX Mainline on Ubuntu from NGINX Inc’s official repository. For other distributions, see the NGINX admin guide. For information on configuring NGINX for production environments, see our Getting Started with NGINX series.

      1. Open /etc/apt/sources.list in a text editor and add the following line to the bottom. Replace CODENAME in this example with the codename of your Ubuntu release. For example, for Ubuntu 18.04, named Bionic Beaver, insert bionic in place of CODENAME below:

        /etc/apt/sources.list
        1
        
        deb http://nginx.org/packages/mainline/ubuntu/ CODENAME nginx
      2. Import the repository’s package signing key and add it to apt:

        sudo wget http://nginx.org/keys/nginx_signing.key
        sudo apt-key add nginx_signing.key
        
      3. Install NGINX:

        sudo apt update
        sudo apt install nginx
        
      4. Ensure NGINX is running and and enabled to start automatically on reboot:

        sudo systemctl start nginx
        sudo systemctl enable nginx
        

      Now that NGINX is installed, configure NGINX to talk to the local Buildbot port. NGINX will listen for SSL traffic using the Let’s Encrypt certificate for your domain.

      1. Create your site’s NGINX configuration file. Ensure that you replace the configuration file’s name example.com.conf with your domain name. Replace all instances of example.com with your Buildbot instance’s URL.

        /etc/nginx/conf.d/example.com.conf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        44
        45
        46
        47
        48
        
        server {
          # Enable SSL and http2
          listen 443 ssl http2 default_server;
        
          server_name example.com;
        
          root html;
          index index.html index.htm;
        
          ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        
          # put a one day session timeout for websockets to stay longer
          ssl_session_cache      shared:SSL:10m;
          ssl_session_timeout  1440m;
        
          ssl_protocols TLSv1.2 TLSv1.3;
          ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
          ssl_prefer_server_ciphers   on;
        
          # force https
          add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
          spdy_headers_comp 5;
        
          proxy_set_header HOST $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto  $scheme;
          proxy_set_header X-Forwarded-Server  $host;
          proxy_set_header X-Forwarded-Host  $host;
        
          location / {
              proxy_pass http://127.0.0.1:8010/;
          }
          location /sse/ {
              # proxy buffering will prevent sse to work
              proxy_buffering off;
              proxy_pass http://127.0.0.1:8010/sse/;
          }
          location /ws {
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
              proxy_pass http://127.0.0.1:8010/ws;
              # raise the proxy timeout for the websocket
              proxy_read_timeout 6000s;
          }
        }
      2. Disable NGINX’s default configuration file:

        mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.disabled
        
      3. Restart NGINX to apply the Buildbot reverse proxy configuration:

        sudo systemctl restart nginx
        
      4. Navigate to your Buildbot instance’s URL over HTTPS. You will see the Buildbot homepage:

        Buildbot Landing Page

        Your continuous integration test server is now up and running.

      5. Ensure that you can log into your Buildbot instance with the admin credentials you created in the Configure Buildbot Master section. Click on the top right hand dropdown menu entitled Anonymous and then, click on Login. A Sign In modal will appear. Enter your credentials to log in to Buildbot as the admin user.

      Install the Buildbot Worker

      In order for Buildbot to execute test builds, the Buildbot master will require a worker. The following steps will setup a worker on the same host as the master.

      1. Install the buildbot-slave Ubuntu package:

        sudo apt-get install -y buildbot-slave
        
      2. Navigate to the directory which will store the Buildbot worker configurations:

        cd /var/lib/buildbot/workers
        
      3. Create the configuration directory for the Buildbot worker. Replace example-worker and my-worker-password with the values used for the c[worker] configuration in the master.cfg file.

        sudo -u buildbot -- buildbot-worker create-worker default localhost example-worker my-worker-password
        
      4. The Buildbot worker is ready to connect to the Buildbot master. Enable the worker process.

        sudo systemctl enable --now [email protected]
        

        Confirm that the worker has connected by going to your Buildbot site and navigating to Builds -> Workers in the sidebar menu:

        Buildbot Workers Page

      Configuring Builds

      Now that Buildbot is installed, you can configure it to run builds. In this tutorial, we will use a forked GitHub repository for the Linode Guides and Tutorials repository to illustrate how to use Buildbot as a system to run tests against a repository.

      Configuring GitHub

      Before creating the build configuration, fork the linode/docs repository into your GitHub account. This is the repository that will be used to run tests against. The repository will also require webhooks to be configured to send push or PR events to Buildbot.

      Note

      The actions you take to fork, add webhook, and push changes to your fork of linode/docs will not affect the parent (or upstream), so you can safely experiment with it. Any changes you make to branches of your fork will remain separate until you submit a pull request to the original linode/docs repository.

      Forking and Configuring the Repository

      1. Log in to your GitHub account and navigate to https://github.com/linode/docs. Click the Fork button:

        GitHub Fork Button

      2. Choose the account to fork the repository into (typically just your username). GitHub will bring you to the page for your own fork of the linode/docs repository.

        Select Settings to browse your fork’s settings:

        GitHub Fork Settings

        Then, select Webhooks from the sidebar:

        GitHub Webhook Settings

      3. Click on the Add webhook button. There are several fields to populate:

        • Under Payload URL enter the domain name for your Buildbot server with the change hook URL path appended to it: https://example.com/change_hook/github.
        • Leave the default value for Content type: application/x-www-form-urlencoded.
        • Under the Secret field, enter the secret value for the c['www']['change_hook_dialects'] option you configure in the master.cfg file.
        • Leave Enable SSL Verification selected.
        • For the Which events would you like to trigger this webhook?, select Let me select individual events and ensure that only the following boxes are checked:
        • Leave Active selected to indicate that GitHub should be configured to send webhooks to Buildbot.
      4. Click on the Add webhook button to save your settings.

        GitHub will return your browser to the list of webhooks for your repository. After configuring a new webhook, GitHub will send a test webhook to the configured payload URL. To indicate whether GitHub was able to send a webhook without errors, it adds a checkmark to the webhook item:

        GitHub Webhook Success

        Github will now send any new pushes made to your fork to your instance of Buildbot for testing.

      Build Prerequisites

      This guide runs builds as a simple process on the Buildbot worker, however, it is possible to execute builds within a Docker container, if desired. Consult the official Buildbot documentation for more information on configuring a Docker set up.

      Most software projects will define several prerequisites and tests for a project build. The Linode Guides and Tutorials repository defines several different tests to run for each build. This example will use one test defined in a python script named blueberry.py. This test checks for broken links, missing images, and more. This test’s dependencies can be installed via pip in a virtualenv.

      On your Linode, install the packages necessary to permit the worker to use a Python virtualenv to create a sandbox during the build.

      sudo apt-get install -y build-essential python3-dev python3-venv
      

      Writing Builds

      The /var/lib/buildbot/masters/ci/master.cfg file contains options to configure builds. The specific sections in the file that include these configurations are the following:

      • WORKERS, define the worker executors the master will connect to in order to run builds.
      • SCHEDULERS, specify how to react to incoming changes.
      • BUILDERS, outline the steps and build tests to run.

      Because the worker has already been configured and connected to the Buildbot master, the only settings necessary to define a custom build are the SCHEDULERS and BUILDERS.

      1. Add the following lines to the end of the /var/lib/buildbot/masters/ci/master.cfg file to define the custom build. Ensure you replace my-username and my-git-repo-name with the values for your own GitHub fork of the linode/docs repository and example-worker with the name of your Buildbot instance’s worker:

        /var/lib/buildbot/masters/ci/master.cfg
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        
        docs_blueberry_test = util.BuildFactory()
        # Clone the repository
        docs_blueberry_test.addStep(
            steps.Git(
                repourl='git://github.com/my-username/my-git-repo-name.git',
                mode='incremental'))
        # Create virtualenv
        docs_blueberry_test.addStep(
            steps.ShellCommand(
                command=["python3", "-m", "venv", ".venv"]))
        # Install test dependencies
        docs_blueberry_test.addStep(
            steps.ShellCommand(
                command=["./.venv/bin/pip", "install", "-r", "ci/requirements.txt"]))
        # Run tests
        docs_blueberry_test.addStep(
            steps.ShellCommand(
                command=["./.venv/bin/python3", "ci/blueberry.py"]))
        # Add the BuildFactory configuration to the master
        c['builders'].append(
            util.BuilderConfig(name="linode-docs",
              workernames=["example-worker"],
              factory=docs_blueberry_test))
            

        The configuration code does the following:

        • A new Build Factory is instantiated. Build Factories define how builds are run.
        • Then, instructions are added to the Build Factory. The Build Factory clones the GitHub fork of the linode/docs repository.
        • Next, a Python virtualenv is setup. This ensures that the dependencies and libraries used for testing are kept separate, in a dedicated sandbox, from the Python libraries on the worker machine.
        • The necessary Python packages used in testing are then installed into the build’s virtualenv.
        • Finally, the blueberry.py testing script is run using the python3 executable from the virtualenv sandbox.
        • The defined Build Factory is then added to the configuration for the master.
      2. Define a simple scheduler to build any branch that is pushed to the GitHub repository. Add the following lines to the end of the master.cfg file:

        ~/buildbox-master/master/master.cfg
        1
        2
        3
        4
        5
        
            ...
        c['schedulers'].append(schedulers.AnyBranchScheduler(
            name="build-docs",
            builderNames=["linode-docs"]))
            

        This code instructs the Buildbot master to create a scheduler that builds any branch for the linode-docs builder. This scheduler will be invoked by the change hook defined for GitHub, which is triggered by the GitHub webhook configured in the GitHub interface.

      3. Restart the Buildbot master now that the custom scheduler and builder have been defined:

        sudo systemctl restart [email protected]
        

      Running Builds

      Navigate to your Buildbot site to view the Builder and Scheduler created in the previous section. In the sidebar click on Build -> Builders. You will see linode-docs listed under the Builder Name heading:

      Buildbot Custom Builder

      A new build can be started for the linode-docs builder. Recall that the GitHub webhook configuration for your fork of linode/docs is set to call Buildbot upon any push or pull request event. To demonstrate how this works:

      1. Clone your fork of the linode/docs repository on your local machine (do not run the following commands on your Buildbot server) and navigate into the cloned repository. Replace username and repository with your own fork’s values:

        git clone https://github.com/username/repository.git
        cd repository
        
      2. Like many git repositories, the linode-docs repository changes often. To ensure that the remaining instructions work as expected, start at a specific revision in the code that is in a known state. Check out revision 76cd31a5271b41ff5a80dee2137dcb5e76296b93:

        git checkout 76cd31a5271b41ff5a80dee2137dcb5e76296b93
        
      3. Create a branch starting at this revision, which is where you will create dummy commits to test your Buildbot master:

        git checkout -b linode-tutorial-demo
        
      4. Create an empty commit so that you have something to push to your fork:

        git commit --allow-empty -m 'Buildbot test'
        
      5. Push your branch to your forked remote GitHub repository:

        git push --set-upstream origin linode-tutorial-demo
        
      6. Navigate to your Buildbot site and go to your running builds. The Home button on the sidebar displays currently executing builds.

        Buildbot running Builds

      7. Click on the running build to view more details. The build will display each step along with logging output:

        Buildbot Build Page

        Each step of the build process can be followed as the build progresses. While the build is running, click on a step to view standard output logs. A successful build will complete each step with an exit code of 0.

        Your Buildbot host will now actively build pushes to any branch or any pull requests to your repository.

      Features to Explore

      Now that you have a simple build configuration for your Buildbot instance, you can continue to add features to your CI server. Some useful functions that Buildbot supports include:

      • Reporters, which can notify you about build failures over IRC, GitHub comments, or email.
      • Workers that execute builds in Docker containers or in temporary cloud instances instead of static hosts.
      • Web server features, including the ability to generate badges for your repository indicating the current build status of the project.

      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.

      Join our Community

      Find answers, ask questions, and help others.

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



      Source link