One place for hosting & domains

      How To Set Up the code-server Cloud IDE Platform on Ubuntu 18.04 [Quickstart]


      Introduction

      code-server is Microsoft Visual Studio Code running on a remote server and accessible directly from your browser. This means that you can use various devices, running different operating systems, and always have a consistent development environment on hand.

      In this tutorial, you will set up the code-server cloud IDE platform on your Ubuntu 18.04 machine and expose it at your domain, secured with Let’s Encrypt. For a more detailed version of this tutorial, please refer to How To Set Up the code-server Cloud IDE Platform on Ubuntu 18.04.

      Prerequisites

      • A server running Ubuntu 18.04 with at least 2GB of RAM, root access, and a sudo, non-root account. You can set this up by following the Initial Server Setup Guide for Ubuntu 18.04.

      • Nginx installed on your server. For a guide on how to do this, complete Steps 1 to 4 of How To Install Nginx on Ubuntu 18.04.

      • A fully registered domain name to host code-server, pointed to your server. This tutorial will use code-server.your-domain throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

        • An A record with your-domain pointing to your server’s public IP address.
        • An A record with www.your-domain pointing to your server’s public IP address.

      Step 1 — Installing code-server

      Create the directory to store all data for code-server:

      Navigate to it:

      Visit the Github releases page of code-server and pick the latest Linux build. Download it using:

      • wget https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      Unpack the archive:

      • tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      Navigate to the directory containing the code-server executable:

      • cd code-server2.1692-vsc1.39.2-linux-x86_64

      To access the code-server executable across your system, copy it with:

      • sudo cp code-server /usr/local/bin

      Create a folder for code-server to store user data:

      • sudo mkdir /var/lib/code-server

      Create a systemd service, code-server.service, in the /lib/systemd/system directory:

      • sudo nano /lib/systemd/system/code-server.service

      Add the following lines:

      /lib/systemd/system/code-server.service

      [Unit]
      Description=code-server
      After=nginx.service
      
      [Service]
      Type=simple
      Environment=PASSWORD=your_password
      ExecStart=/usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password
      Restart=always
      
      [Install]
      WantedBy=multi-user.target
      
      • --host 127.0.0.1 binds it to localhost.
      • --user-data-dir /var/lib/code-server sets its user data directory.
      • --auth password specifies that it should authenticate visitors with a password.

      Remember to replace your_password with your desired password.

      Save and close the file.

      Start the code-server service:

      • sudo systemctl start code-server

      Check that it’s started correctly:

      • sudo systemctl status code-server

      You’ll see output similar to:

      Output

      ● code-server.service - code-server Loaded: loaded (/lib/systemd/system/code-server.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2019-12-09 20:07:28 UTC; 4s ago Main PID: 5216 (code-server) Tasks: 23 (limit: 2362) CGroup: /system.slice/code-server.service ├─5216 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password └─5240 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password ...

      Enable the code-server service to start automatically after a server reboot:

      • sudo systemctl enable code-server

      Step 2 — Exposing code-server

      Now you will configure Nginx as a reverse proxy for code-server.

      Create code-server.conf to store the configuration for exposing code-server at your domain:

      • sudo nano /etc/nginx/sites-available/code-server.conf

      Add the following lines to set up your server block with the necessary directives:

      /etc/nginx/sites-available/code-server.conf

      server {
          listen 80;
          listen [::]:80;
      
          server_name code-server.your_domain;
      
          location / {
              proxy_pass http://localhost:8080/;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection upgrade;
              proxy_set_header Accept-Encoding gzip;
          }
      }
      

      Replace code-server.your_domain with your desired domain, then save and close the file.

      To make this site configuration active, create a symlink of it:

      • sudo ln -s /etc/nginx/sites-available/code-server.conf /etc/nginx/sites-enabled/code-server.conf

      Test the validity of the configuration:

      You’ll see the following output:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      For the configuration to take effect, restart Nginx:

      • sudo systemctl restart nginx

      Step 3 — Securing Your Domain

      Now you’ll secure your domain using a Let’s Encrypt TLS certificate.

      Add the Certbot package repository to your server:

      • sudo add-apt-repository ppa:certbot/certbot

      Install Certbot and its Nginx plugin:

      • sudo apt install python-certbot-nginx

      Configure ufw to accept encrypted traffic:

      The output will be:

      Output

      Rule added Rule added (v6)

      Reload it for the configuration to take effect:

      The output will show:

      Output

      Firewall reloaded

      Navigate to your code-server domain.

      code-server login prompt

      Enter your code-server password. You’ll see the interface exposed at your domain.

      code-server GUI

      To secure it, install a Let’s Encrypt TLS certificate using Certbot.

      Request a certificate for your domain with:

      • sudo certbot --nginx -d code-server.your_domain

      Provide an email address for urgent notices, accept the EFF’s Terms of Service, and decide whether to redirect all HTTP traffic to HTTPS.

      The output will be similar to this:

      Output

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/code-server.your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/code-server.your_domain/privkey.pem Your cert will expire on ... To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" ...

      Certbot has successfully generated TLS certificates and applied them to the Nginx configuration for your domain.

      Conclusion

      You now have code-server, a versatile cloud IDE, installed on your Ubuntu 18.04 server, exposed at your domain and secured using Let’s Encrypt certificates. For further information, see the Visual Studio Code documentation for additional features and detailed instructions on other components of code-server.



      Source link

      How to Use Ansible to Install and Set Up WordPress with LAMP on Ubuntu 18.04


      Introduction

      Server automation now plays an essential role in systems administration, due to the disposable nature of modern application environments. Configuration management tools such as Ansible are typically used to streamline the process of automating server setup by establishing standard procedures for new servers while also reducing human error associated with manual setups.

      Ansible offers a simple architecture that doesn’t require special software to be installed on nodes. It also provides a robust set of features and built-in modules which facilitate writing automation scripts.

      This guide explains how to use Ansible to automate the steps contained in our guide on How To Install WordPress with LAMP on Ubuntu 18.04. WordPress is the most popular CMS (content management system) on the internet, allowing users to set up flexible blogs and websites on top of a MySQL backend with PHP processing. After setup, almost all administration can be done through the web frontend.

      Prerequisites

      In order to execute the automated setup provided by the playbook we’re discussing in this guide, you’ll need:

      Before proceeding, you first need to make sure your Ansible control node is able to connect and execute commands on your Ansible host(s). For a connection test, please check step 3 of How to Install and Configure Ansible on Ubuntu 18.04.

      What Does this Playbook Do?

      This Ansible playbook provides an alternative to manually running through the procedure outlined in our guide on How To Install WordPress with LAMP on Ubuntu 18.04.

      Running this playbook will perform the following actions on your Ansible hosts:

      1. Install aptitude, which is preferred by Ansible as an alternative to the apt package manager.
      2. Install the required LAMP packages and PHP extensions.
      3. Create and enable a new Apache VirtualHost for the WordPress website.
      4. Enable the Apache rewrite (mod_rewrite) module.
      5. Disable the default Apache website.
      6. Set the password for the MySQL root user.
      7. Remove anonymous MySQL accounts and the test database.
      8. Create a new MySQL database and user for the WordPress website.
      9. Set up UFW to allow HTTP traffic on the configured port (80 by default).
      10. Download and unpack WordPress.
      11. Set up correct directory ownership and permissions.
      12. Set up the wp-config.php file using the provided template.

      Once the playbook has finished running, you will have a WordPress installation running on top of a LAMP environment, based on the options you defined within your configuration variables.

      How to Use this Playbook

      The first thing we need to do is obtain the WordPress on LAMP playbook and its dependencies from the do-community/ansible-playbooks repository. We need to clone this repository to a local folder inside the Ansible Control Node.

      In case you have cloned this repository before while following a different guide, access your existing ansible-playbooks copy and run a git pull command to make sure you have updated contents:

      • cd ~/ansible-playbooks
      • git pull

      If this is your first time using the do-community/ansible-playbooks repository, you should start by cloning the repository to your home folder with:

      • cd ~
      • git clone https://github.com/do-community/ansible-playbooks.git
      • cd ansible-playbooks

      The files we’re interested in are located inside the wordpress-lamp_ubuntu1804 folder, which has the following structure:

      wordpress-lamp_ubuntu1804
      ├── files
      │   ├── apache.conf.j2
      │   └── wp-config.php.j2
      ├── vars
      │   └── default.yml
      ├── playbook.yml
      └── readme.md
      

      Here is what each of these files are:

      • files/apache.conf.j2: Template file for setting up the Apache VirtualHost.
      • files/wp-config.php.j2: Template file for setting up WordPress’s configuration file.
      • vars/default.yml: Variable file for customizing playbook settings.
      • playbook.yml: The playbook file, containing the tasks to be executed on the remote server(s).
      • readme.md: A text file containing information about this playbook.

      We’ll edit the playbook’s variable file to customize its options. Access the wordpress-lamp_ubuntu1804 directory and open the vars/default.yml file using your command line editor of choice:

      • cd wordpress-lamp_ubuntu1804
      • nano vars/default.yml

      This file contains a few variables that require your attention:

      vars/default.yml

      ---
      #System Settings
      php_modules: [ 'php-curl', 'php-gd', 'php-mbstring', 'php-xml', 'php-xmlrpc', 'php-soap', 'php-intl', 'php-zip' ]
      
      #MySQL Settings
      mysql_root_password: "mysql_root_password"
      mysql_db: "wordpress"
      mysql_user: "sammy"
      mysql_password: "password"
      
      #HTTP Settings
      http_host: "your_domain"
      http_conf: "your_domain.conf"
      http_port: "80"
      

      The following list contains a brief explanation of each of these variables and how you might want to change them:

      • php_modules: An array containing PHP extensions that should be installed to support your WordPress setup. You don’t need to change this variable, but you might want to include new extensions to the list if your specific setup requires it.
      • mysql_root_password: The desired password for the root MySQL account.
      • mysql_db: The name of the MySQL database that should be created for WordPress.
      • mysql_user: The name of the MySQL user that should be created for WordPress.
      • mysql_password: The password for the new MySQL user.
      • http_host: Your domain name.
      • http_conf: The name of the configuration file that will be created within Apache.
      • http_port: HTTP port for this virtual host, where 80 is the default.

      Once you’re done updating the variables inside vars/default.yml, save and close this file. If you used nano, do so by pressing CTRL + X, Y, then ENTER.

      You’re now ready to run this playbook on one or more servers. Most playbooks are configured to be executed on every server in your inventory, by default. We can use the -l flag to make sure that only a subset of servers, or a single server, is affected by the playbook. We can also use the -u flag to specify which user on the remote server we’re using to connect and execute the playbook commands on the remote hosts.

      To execute the playbook only on server1, connecting as sammy, you can use the following command:

      • ansible-playbook playbook.yml -l server1 -u sammy

      You will get output similar to this:

      Output

      PLAY [all] ***************************************************************************************************************************** TASK [Gathering Facts] ***************************************************************************************************************** ok: [server1] TASK [Install prerequisites] *********************************************************************************************************** ok: [server1] … TASK [Download and unpack latest WordPress] ******************************************************************************************** changed: [server1] TASK [Set ownership] ******************************************************************************************************************* changed: [server1] TASK [Set permissions for directories] ************************************************************************************************* changed: [server1] TASK [Set permissions for files] ******************************************************************************************************* changed: [server1] TASK [Set up wp-config] **************************************************************************************************************** changed: [server1] RUNNING HANDLER [Reload Apache] ******************************************************************************************************** changed: [server1] RUNNING HANDLER [Restart Apache] ******************************************************************************************************* changed: [server1] PLAY RECAP ***************************************************************************************************************************** server1 : ok=22 changed=18 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      Note: For more information on how to run Ansible playbooks, check our Ansible Cheat Sheet Guide.

      When the playbook is finished running, you can go to your web browser to finish WordPress’s installation from there.

      Navigate to your server’s domain name or public IP address:

      http://server_host_or_IP
      

      You will see a page like this:

      WordPress language selection page

      After selecting the language you’d like to use for your WordPress installation, you’ll be presented with a final step to set up your WordPress user and password so you can log into your control panel:

      WordPress Setup

      When you click ahead, you will be taken to a page that prompts you to log in:

      WP login prompt

      Once you log in, you will be taken to the WordPress administration dashboard:

      WP Admin Panel

      Some common next steps for customizing your WordPress installation include choosing the permalinks setting for your posts (can be found in Settings > Permalinks) and selecting a new theme (in Appearance > Themes).

      The Playbook Contents

      You can find the WordPress on LAMP server setup featured in this tutorial in the wordpress-lamp_ubuntu1804 folder inside the DigitalOcean Community Playbooks repository. To copy or download the script contents directly, click the Raw button towards the top of each script.

      The full contents of the playbook as well as its associated files are also included here for your convenience.

      vars/default.yml

      The default.yml variable file contains values that will be used within the playbook tasks, such as the database settings and the domain name to configure within Apache.

      vars/default.yml

      #System Settings
      php_modules: [ 'php-curl', 'php-gd', 'php-mbstring', 'php-xml', 'php-xmlrpc', 'php-soap', 'php-intl', 'php-zip' ]
      
      #MySQL Settings
      mysql_root_password: "mysql_root_password"
      mysql_db: "wordpress"
      mysql_user: "sammy"
      mysql_password: "password"
      
      #HTTP Settings
      http_host: "your_domain"
      http_conf: "your_domain.conf"
      http_port: "80"
      

      files/apache.conf.j2

      The apache.conf.j2 file is a Jinja 2 template file that configures a new Apache VirtualHost. The variables used within this template are defined in the vars/default.yml variable file.

      files/apache.conf.j2

      <VirtualHost *:{{ http_port }}>
         ServerAdmin webmaster@localhost
         ServerName {{ http_host }}
         ServerAlias www.{{ http_host }}
         DocumentRoot /var/www/{{ http_host }}
         ErrorLog ${APACHE_LOG_DIR}/error.log
         CustomLog ${APACHE_LOG_DIR}/access.log combined
      
         <Directory /var/www/{{ http_host }}>
               Options -Indexes
         </Directory>
      
         <IfModule mod_dir.c>
             DirectoryIndex index.php index.html index.cgi index.pl  index.xhtml index.htm
         </IfModule>
      
      </VirtualHost>
      

      files/wp-config.php.j2

      The wp-config.php.j2 file is another Jinja template, used to set up the main configuration file used by WordPress. The variables used within this template are defined in the vars/default.yml variable file. Unique authentication keys and salts are generated using a hash function.

      files/info.php.j2

      <?php
      /**
       * The base configuration for WordPress
       *
       * The wp-config.php creation script uses this file during the
       * installation. You don't have to use the web site, you can
       * copy this file to "wp-config.php" and fill in the values.
       *
       * This file contains the following configurations:
       *
       * * MySQL settings
       * * Secret keys
       * * Database table prefix
       * * ABSPATH
       *
       * @link https://codex.wordpress.org/Editing_wp-config.php
       *
       * @package WordPress
       */
      
      // ** MySQL settings - You can get this info from your web host ** //
      /** The name of the database for WordPress */
      define( 'DB_NAME', '{{ mysql_db }}' );
      
      /** MySQL database username */
      define( 'DB_USER', '{{ mysql_user }}' );
      
      /** MySQL database password */
      define( 'DB_PASSWORD', '{{ mysql_password }}' );
      
      /** MySQL hostname */
      define( 'DB_HOST', 'localhost' );
      
      /** Database Charset to use in creating database tables. */
      define( 'DB_CHARSET', 'utf8' );
      
      /** The Database Collate type. Don't change this if in doubt. */
      define( 'DB_COLLATE', '' );
      
      /** Filesystem access **/
      define('FS_METHOD', 'direct');
      
      /**#@+
       * Authentication Unique Keys and Salts.
       *
       * Change these to different unique phrases!
       * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
       * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
       *
       * @since 2.6.0
       */
      define( 'AUTH_KEY',         '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'SECURE_AUTH_KEY',  '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'LOGGED_IN_KEY',    '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'NONCE_KEY',        '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'AUTH_SALT',        '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'SECURE_AUTH_SALT', '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'LOGGED_IN_SALT',   '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      define( 'NONCE_SALT',       '{{ ansible_date_time.iso8601_micro | hash('sha256') }}' );
      
      /**#@-*/
      
      /**
       * WordPress Database Table prefix.
       *
       * You can have multiple installations in one database if you give each
       * a unique prefix. Only numbers, letters, and underscores please!
       */
      $table_prefix = 'wp_';
      
      /**
       * For developers: WordPress debugging mode.
       *
       * Change this to true to enable the display of notices during development.
       * It is strongly recommended that plugin and theme developers use WP_DEBUG
       * in their development environments.
       *
       * For information on other constants that can be used for debugging,
       * visit the Codex.
       *
       * @link https://codex.wordpress.org/Debugging_in_WordPress
       */
      define( 'WP_DEBUG', false );
      
      /* That's all, stop editing! Happy publishing. */
      
      /** Absolute path to the WordPress directory. */
      if ( ! defined( 'ABSPATH' ) ) {
          define( 'ABSPATH', dirname( __FILE__ ) . '/' );
      }
      
      /** Sets up WordPress vars and included files. */
      require_once( ABSPATH . 'wp-settings.php' );
      
      

      playbook.yml

      The playbook.yml file is where all tasks from this setup are defined. It starts by defining the group of servers that should be the target of this setup (all), after which it uses become: true to define that tasks should be executed with privilege escalation (sudo) by default. Then, it includes the vars/default.yml variable file to load configuration options.

      playbook.yml

      ---
      - hosts: all
        become: true
        vars_files:
          - vars/default.yml
      
        tasks:
          - name: Install prerequisites
            apt: name=aptitude update_cache=yes state=latest force_apt_get=yes
            tags: [ system ]
      
          - name: Install LAMP Packages
            apt: name={{ item }} update_cache=yes state=latest
            loop: [ 'apache2', 'mysql-server', 'python3-pymysql', 'php', 'php-mysql', 'libapache2-mod-php' ]
            tags: [ system ]
      
          - name: Install PHP Extensions
            apt: name={{ item }} update_cache=yes state=latest
            loop: "{{ php_modules }}"
            tags: [ system ]
      
        # Apache Configuration
          - name: Create document root
            file:
              path: "/var/www/{{ http_host }}"
              state: directory
              owner: "www-data"
              group: "www-data"
              mode: '0755'
            tags: [ apache ]
      
          - name: Set up Apache VirtualHost
            template:
              src: "files/apache.conf.j2"
              dest: "/etc/apache2/sites-available/{{ http_conf }}"
            notify: Reload Apache
            tags: [ apache ]
      
          - name: Enable rewrite module
            shell: /usr/sbin/a2enmod rewrite
            notify: Reload Apache
            tags: [ apache ]
      
          - name: Enable new site
            shell: /usr/sbin/a2ensite {{ http_conf }}
            notify: Reload Apache
            tags: [ apache ]
      
          - name: Disable default Apache site
            shell: /usr/sbin/a2dissite 000-default.conf
            notify: Restart Apache
            tags: [ apache ]
      
        # MySQL Configuration
          - name: Set the root password
            mysql_user:
              name: root
              password: "{{ mysql_root_password }}"
              login_unix_socket: /var/run/mysqld/mysqld.sock
            tags: [ mysql, mysql-root ]
      
          - name: Remove all anonymous user accounts
            mysql_user:
              name: ''
              host_all: yes
              state: absent
              login_user: root
              login_password: "{{ mysql_root_password }}"
            tags: [ mysql ]
      
          - name: Remove the MySQL test database
            mysql_db:
              name: test
              state: absent
              login_user: root
              login_password: "{{ mysql_root_password }}"
            tags: [ mysql ]
      
          - name: Creates database for WordPress
            mysql_db:
              name: "{{ mysql_db }}"
              state: present
              login_user: root
              login_password: "{{ mysql_root_password }}"
            tags: [ mysql ]
      
          - name: Create MySQL user for WordPress
            mysql_user:
              name: "{{ mysql_user }}"
              password: "{{ mysql_password }}"
              priv: "{{ mysql_db }}.*:ALL"
              state: present
              login_user: root
              login_password: "{{ mysql_root_password }}"
            tags: [ mysql ]
      
        # UFW Configuration
          - name: "UFW - Allow HTTP on port {{ http_port }}"
            ufw:
              rule: allow
              port: "{{ http_port }}"
              proto: tcp
            tags: [ system ]
      
        # WordPress Configuration
          - name: Download and unpack latest WordPress
            unarchive:
              src: https://wordpress.org/latest.tar.gz
              dest: "/var/www/{{ http_host }}"
              remote_src: yes
              creates: "/var/www/{{ http_host }}/wordpress"
            tags: [ wordpress ]
      
          - name: Set ownership
            file:
              path: "/var/www/{{ http_host }}"
              state: directory
              recurse: yes
              owner: www-data
              group: www-data
            tags: [ wordpress ]
      
          - name: Set permissions for directories
            shell: "/usr/bin/find /var/www/{{ http_host }}/wordpress/ -type d -exec chmod 750 {} \;"
            tags: [ wordpress ]
      
          - name: Set permissions for files
            shell: "/usr/bin/find /var/www/{{ http_host }}/wordpress/ -type f -exec chmod 640 {} \;"
            tags: [ wordpress ]
      
          - name: Set up wp-config
            template:
              src: "files/wp-config.php.j2"
              dest: "/var/www/{{ http_host }}/wordpress/wp-config.php"
            tags: [ wordpress ]
      
        handlers:
          - name: Reload Apache
            service:
              name: apache2
              state: reloaded
      
          - name: Restart Apache
            service:
              name: apache2
              state: restarted
      

      Feel free to modify these files to best suit your individual needs within your own workflow.

      Conclusion

      In this guide, we used Ansible to automate the process of installing and setting up a WordPress website with LAMP on an Ubuntu 18.04 server.

      If you’d like to include other tasks in this playbook to further customize your server setup, please refer to our introductory Ansible guide Configuration Management 101: Writing Ansible Playbooks.



      Source link

      How To Set Up the code-server Cloud IDE Platform on CentOS 7


      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      With developer tools moving to the cloud, creation and adoption of cloud IDE (Integrated Development Environment) platforms is growing. Cloud IDEs allow for real-time collaboration between developer teams to work in a unified development environment that minimizes incompatibilities and enhances productivity. Accessible through web browsers, cloud IDEs are available from every type of modern device.

      code-server is Microsoft Visual Studio Code running on a remote server and accessible directly from your browser. Visual Studio Code is a modern code editor with integrated Git support, a code debugger, smart autocompletion, and customizable and extensible features. This means that you can use various devices running different operating systems, and always have a consistent development environment on hand.

      In this tutorial, you will set up the code-server cloud IDE platform on your CentOS 7 machine and expose it at your domain, secured with free Let’s Encrypt TLS certificates. In the end, you’ll have Microsoft Visual Studio Code running on your CentOS 7 server, available at your domain and protected with a password.

      Prerequisites

      • A server running CentOS 7 with at least 2GB RAM, root access, and a sudo, non-root account. You can set this up by following this initial server setup guide.

      • Nginx installed on your server. For a guide on how to do this, see How To Install Nginx on CentOS 7.

      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

        • An A record with your-domain pointing to your server’s public IP address.
        • An A record with www.your-domain pointing to your server’s public IP address.
      • A fully registered domain name to host code-server, pointed to your server. This tutorial will use code-server.your-domain throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

      Step 1 — Installing code-server

      In this section, you will set up code-server on your server. This entails downloading the latest version and creating a systemd service that will keep code-server always running in the background. You’ll also specify a restart policy for the service, so that code-server stays available after possible crashes or reboots.

      You’ll store all data pertaining to code-server in a folder named ~/code-server. Create it by running the following command:

      Navigate to it:

      You’ll need to head over to the Github releases page of code-server and pick the latest Linux build (the file will contain ‘linux’ in its name). At the time of writing, the latest version was 2.1692. Download it using curl by running the following command:

      • curl -LO https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      Then, unpack the archive by running:

      • tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      You’ll get a folder named exactly as the original file you downloaded, which contains the code-server executable. Navigate to it:

      • cd code-server2.1692-vsc1.39.2-linux-x86_64

      Copy the code-server executable to /usr/local/bin so you’ll be able to access it system wide by running the following command:

      • sudo cp code-server /usr/local/bin

      Next, create a folder for code-server, where it will store user data:

      • sudo mkdir /var/lib/code-server

      Now that you’ve downloaded code-server and made it available system-wide, you will create a systemd service to keep code-server running in the background at all times.

      You’ll store the service configuration in a file named code-server.service, in the /usr/lib/systemd/system directory, where systemd stores its services. Create it using the vi editor:

      • sudo vi /usr/lib/systemd/system/code-server.service

      Add the following lines:

      /usr/lib/systemd/system/code-server.service

      [Unit]
      Description=code-server
      After=nginx.service
      
      [Service]
      Type=simple
      Environment=PASSWORD=your_password
      ExecStart=/usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password
      Restart=always
      
      [Install]
      WantedBy=multi-user.target
      

      Here you first specify the description of the service. Then, you state that the nginx service must be started before this one. After the [Unit] section, you define the type of the service (simple means that the process should be simply run) and provide the command that will be executed.

      You also specify that the global code-server executable should be started with a few arguments specific to code-server. --host 127.0.0.1 binds it to localhost, so it’s only directly accessible from inside of your server. --user-data-dir /var/lib/code-server sets its user data directory, and --auth password specifies that it should authenticate visitors with a password, specified in the PASSWORD environment variable declared on the line above it.

      Remember to replace your_password with your desired password. Type :wq and then ENTER to save and close the file.

      The next line tells systemd to restart code-server in all malfunction events (for example, when it crashes or the process is killed). The [Install] section orders systemd to start this service when it becomes possible to log in to your server.

      Start the code-server service by running the following command:

      • sudo systemctl start code-server

      Check that it’s started correctly by observing its status:

      • sudo systemctl status code-server

      You’ll see output similar to:

      Output

      ● code-server.service - code-server Loaded: loaded (/usr/lib/systemd/system/code-server.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2019-12-19 19:24:42 UTC; 5s ago Main PID: 1668 (code-server) CGroup: /system.slice/code-server.service ├─1668 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password └─1679 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password Dec 19 19:24:42 code-server-centos systemd[1]: Started code-server. Dec 19 19:24:44 code-server-centos code-server[1668]: info Server listening on http://127.0.0.1:8080 Dec 19 19:24:44 code-server-centos code-server[1668]: info - Using custom password for authentication Dec 19 19:24:44 code-server-centos code-server[1668]: info - Not serving HTTPS

      To make code-server start automatically after a server reboot, enable its service by running the following command:

      • sudo systemctl enable code-server

      In this step, you’ve downloaded code-server and made it available globally. Then, you’ve created a systemd service for it and enabled it, so code-server will start at every server boot. Next, you’ll expose it at your domain by configuring Nginx to serve as a reverse proxy between the visitor and code-server.

      Step 2 — Exposing code-server at Your Domain

      In this section, you will configure Nginx as a reverse proxy for code-server.

      As you have learned in the Nginx prerequisite step, its site configuration files are stored under /etc/nginx/conf.d and will automatically be loaded when Nginx starts.

      You’ll store the configuration for exposing code-server at your domain in a file named code-server.conf, under /etc/nginx/conf.d. Start off by creating it using your editor:

      • sudo vi /etc/nginx/conf.d/code-server.conf

      Add the following lines:

      /etc/nginx/conf.d/code-server.conf

      server {
          listen 80;
          listen [::]:80;
      
          server_name code-server.your-domain;
      
          location / {
              proxy_pass http://localhost:8080/;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection upgrade;
              proxy_set_header Accept-Encoding gzip;
          }
      }
      

      Replace code-server.your-domain with your desired domain, then save and close the file.

      In this file, you define that Nginx should listen to HTTP port 80. Then, you specify a server_name that tells Nginx for which domain to accept requests and apply this particular configuration.

      In the next block, for the root location (/), you specify that requests should be passed back and forth to code-server running at localhost:8080. The next three lines (starting with proxy_set_header) order Nginx to carry over some HTTP request headers that are needed for correct functioning of WebSockets, which code-server extensively uses.

      To test the validity of the configuration, run the following command:

      You’ll see the following output:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      For the configuration to take effect, you’ll need to restart Nginx:

      • sudo systemctl restart nginx

      CentOS 7 comes with SELinux turned on, with a strict ruleset, which by default does not permit Nginx to connect to local TCP sockets. Nginx needs to do in order to serve as a reverse proxy for code-server. Run the following command to relax the rule permanently:

      • sudo setsebool httpd_can_network_connect 1 -P

      Then, in your browser, navigate to the domain you used for code-server. You will see the code-server login prompt.

      code-server login prompt

      code-server is asking you for your password. Enter the one you set in the previous step and press Enter IDE. You’ll now enter code-server and immediately see its editor GUI.

      code-server GUI

      You now have your code-server installation accessible at your domain. In the next step, you’ll secure it by applying a free Let’s Encrypt TLS certificate.

      Step 3 — Securing Your Domain

      In this section, you will secure your domain using a Let’s Encrypt TLS certificate, which you’ll provision using Certbot.

      To install the latest version of Certbot and its Nginx plugin, run the following command:

      • sudo yum install certbot python2-certbot-nginx

      To request certificates for your domain, run the following command:

      • sudo certbot --nginx -d code-server.your-domain

      In this command, you run certbot to request certificates for your domain—you pass the domain name with the -d parameter. The --nginx flag tells it to automatically change Nginx site configuration to support HTTPS. Remember to replace code-server.your-domain with your domain name.

      If this is your first time running Certbot, you’ll be asked to provide an email address for urgent notices and to accept the EFF’s Terms of Service. Certbot will then request certificates for your domain from Let’s Encrypt. It will then ask you if you’d like to redirect all HTTP traffic to HTTPS:

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

      It is recommended to select the second option in order to maximize security. After you input your selection, press ENTER.

      The output will be similar to this:

      Output

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/code-server.your-domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/code-server.your-domain/privkey.pem Your cert will expire on ... To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      This means that Certbot has sucessfully generated TLS certificates and applied them to the Nginx configuration for your domain. You can now reload your code-server domain in your browser and observe a padlock to the left of the site address, which means that your connection is properly secured.

      Now you’ll make Certbot automatically renew the certificates before they expire. To run the renewal check daily, you’ll use cron, a standard system service for running periodic jobs. You direct cron by opening and editing a file called a crontab:

      This command will open the default crontab, which is currently an empty text file. Add the following line, then save and close it:

      crontab

      . . .
      15 3 * * * /usr/bin/certbot renew --quiet
      

      15 3 * * * will run the following command at 3:15 am every day—you can adapt this to any time.

      The renew command for Certbot will check all certificates installed on the system and update any that are set to expire in less than thirty days. --quiet tells Certbot not to output information or wait for user input.

      cron will now run this command daily. All installed certificates will be automatically renewed and reloaded when they have thirty days or less before they expire.

      Now that you have code-server accessible at your domain through a secured Nginx reverse proxy, you’re ready to review the user interface of code-server.

      Step 4 — Using the code-server Interface

      In this section, you’ll use some of the features of the code-server interface. Since code-server is Visual Studio Code running in the cloud, it has the same interface as the standalone desktop edition.

      On the left-hand side of the IDE, there is a vertical row of six buttons opening the most commonly used features in a side panel known as the Activity Bar.

      code-server GUI - Sidepanel

      This bar is customizable so you can move these views to a different order or remove them from the bar. By default, the first button opens the general menu in a dropdown, while the second view opens the Explorer panel that provides tree-like navigation of the project’s structure. You can manage your folders and files here—creating, deleting, moving, and renaming them as necessary. The next view provides access to a search and replace functionality.

      Following this, in the default order, is your view of the source control systems, like Git. Visual Studio code also supports other source control providers and you can find further instructions for source control work flows with the editor in this documentation.

      Git pane with context-menu open

      The debugger option on the Activity Bar provides all the common actions for debugging in the panel. Visual Studio Code comes with built-in support for the Node.js runtime debugger and any language that transpiles to Javascript. For other languages you can install extensions for the required debugger. You can save debugging configurations in the launch.json file.

      Debugger View with launch.json open

      The final view in the Activity Bar provides a menu to access available extensions on the Marketplace.

      code-server GUI - Tabs

      The central part of the GUI is your editor, which you can separate by tabs for your code editing. You can change your editing view to a grid system or to side-by-side files.

      Editor Grid View

      After creating a new file through the File menu, an empty file will open in a new tab, and once saved, the file’s name will be viewable in the Explorer side panel. Creating folders can be done by right clicking on the Explorer sidebar and clicking on New Folder. You can expand a folder by clicking on its name as well as dragging and dropping files and folders to upper parts of the hierarchy to move them to a new location.

      code-server GUI - New Folder

      You can gain access to a terminal by entering CTRL+SHIFT+`, or by clicking on Terminal in the upper menu dropdown, and selecting New Terminal. The terminal will open in a lower panel and its working directory will be set to the project’s workspace, which contains the files and folders shown in the Explorer side panel.

      You’ve explored a high-level overview of the code-server interface and reviewed some of the most commonly used features.

      Conclusion

      You now have code-server, a versatile cloud IDE, installed on your CentOS 7 server, exposed at your domain and secured using Let’s Encrypt certificates. You can now work on projects individually, as well as in a team-collaboration setting. Running a cloud IDE frees resources on your local machine and allows you to scale the resources when needed. For further information, see the Visual Studio Code documentation for additional features and detailed instructions on other components of code-server.

      If you would like to run code-server on your DigitalOcean Kubernetes cluster check out our tutorial on How To Set Up the code-server Cloud IDE Platform on DigitalOcean Kubernetes.



      Source link