One place for hosting & domains

      Environment

      How To Use Vue.js Environment Modes with a Node.js Mock Data Layer


      The author selected Open Sourcing Mental Illness to receive a donation as part of the Write for DOnations program.

      Introduction

      When it comes to software development, there are two ends of the stack. A stack is a collection of technologies used for your software to function. Vue.js, the progressive user interface framework, is part of the frontend, the part of the stack that a user directly interacts with. This frontend is also referred to as the client and encompasses everything that is rendered in the user’s browser. Technologies such as HTML, JavaScript, and CSS are all rendered in the client. In contrast, the backend commonly interacts with data or servers through technologies like Java, Kotlin, or .NET.

      The application is the data itself, and the interface (frontend) is a way to display data meaningfully to the user for them to interact with. In the begining phase of software development, you don’t need a backend to get started. In some cases, the backend hasn’t even been created yet. In a case such as this, you can create your own local data to build your interface. Using Node environments and variables, you can toggle different datasets per environment or toggle between local data and “live” data via a network call. Having a mock data layer is useful if you do not have data yet, because it provides data to test your frontend before the backend is ready.

      By the end of this tutorial, you will have created several Node environments and toggled these datasets with Node environment variables. To illustrate these concepts, you will create a number of Vue components to visualize this data across environments.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Creating Environments with Modes

      Modes are an important concept when it comes to Vue CLI projects. A mode is an environment type, or a set of variables that gets loaded during a build. These variables are stored in .env files in the root directory of your project. As part of the default vue-cli-service plugin, you immediately have access to three modes. These are:

      • development: used when vue-cli-service serve is executed.
      • test: used when vue-cli-service test:unit is executed.
      • production: used when vue-cli-service build and vue-cli-service test:e2e are executed.

      Perhaps the most used mode is development mode. This is the mode that Vue.js developers use when working on their application on their local machine. This mode starts a local Node server with hot-module reloading (instant browser refreshing) enabled. The test mode, on the other hand, is a mode to run your unit tests in. Unit tests are JavaScript functions that test application methods, events, and in some cases, user interaction. The last default mode is production. This compressess all of your code and optimizes it for performance so it can be hosted on a production server.

      The project that is generated for you from Vue CLI has these commands pre-mapped to npm run serve, npm run test:unit, and npm run build.

      Each environment is associated with its own .env file, where you can put custom Node environment key/value pairs that your application can reference. You will not have these files after generating a project from the CLI, but you can add these using one command in your terminal.

      You will now generate a development environment file, which you will use later in the tutorial. Open your terminal and enter the following in the root directory of your project:

      Open the newly created file in your text editor of choice. In this file, you’ll want to explicitly define the environment type. This is a key/value pair that could be anything you want. However, it’s considered best practice to define the environment type that corresponds with the name of the .env file.

      You will be using this NODE_ENV later in the tutorial by loading different data sets depending on the environment or mode selected on build. Add the following line:

      .env.development

      NODE_ENV="development"
      

      Save and exit the file.

      The key/value pairs in this file will only affect your program when the application is in development mode. It’s important to note that Git will automatically commit these files unless you add the file in your .gitignore file or append the .local extension to the file name: .env.development.local.

      You are not limited to the standard environments that Vue.js provides. You may have several other environments that are specific to your workflow. Next, you’ll create a custom environment for a staging server.

      Start by creating the .env file for the staging environment. Open your terminal of choice and in the root directory run the following:

      In this file, create a key/value pair that’ll define the NODE_ENV of this project. You may open this file in your text editor of choice, or you can modify it using the terminal. Nano is an editor that is used in the terminal window. You may have other editors such as Vim.

      You will be using this NODE_ENV later in the tutorial by loading different data sets depending on the environment or mode selected on build.

      Add the following to the file:

      .env.staging

      NODE_ENV="staging"
      

      Save and exit the file. In nano, you can save the file with CTRL+X then CTRL+Y.

      In order to use this environment, you can register a new script in your package.json file. Open this file now.

      In the "scripts" section, add the following highlighted line:

      package.json

      {
        ...
        "scripts": {
          ...
          "staging": "vue-cli-service serve --mode staging",
        },
        ...
      }
      

      Save this file, then exit the editor.

      You’ve just created a new script that can be executed with npm run staging. The flag --mode lets Vue CLI know to use the .env.staging (or .env.staging.local) file when starting the local server.

      In this step, you created custom NODE_ENV variables for two Vue.js modes: development and staging. These modes will come in handy in the following steps when you create custom datasets for each of these modes. By running the project in one mode or the other, you can load different data sets by reading these files.

      Step 2 — Creating a Mock Data Layer

      As stated in the Introduction, you can start developing your user interface without a backend by using a mock data layer. A mock data layer is static data that is stored locally for your application to reference. When working with Vue, these data files are JavaScript objects and arrays. Where these are stored is your personal preference. For the sake of this tutorial, mock data files will be stored in a directory named data.

      In this tutorial, you’re building a “main/detail” airport browser application. In the “main” view, the user will see a number of airport codes and locations.

      In your terminal, in the root project directory, create a new directory using the mkdir command:

      Now create a .js file named airports.staging.mock.js using the touch command. Naming these files is personal preference, but it’s generally a good idea to differentiate this mock data from essential files in your app. For the sake of this tutorial, mock files will follow this naming convention: name.environment.mock.js.

      Create the file with the following command:

      • touch data/airports.staging.mock.js

      In your editor of choice, open this newly created JavaScript file and add the following array of objects:

      data/airports.staging.mock.js

      const airports = [
          {
              name: 'Cincinnati/Northern Kentucky International Airport',
              abbreviation: 'CVG',
              city: 'Hebron',
              state: 'KY'
          },
          {
              name: 'Seattle-Tacoma International Airport',
              abbreviation: 'SEA',
              city: 'Seattle',
              state: 'WA'
          },
          {
              name: 'Minneapolis-Saint Paul International Airport',
              abbreviation: 'MSP',
              city: 'Bloomington',
              state: 'MN'
          }
      ]
      
      export default airports
      

      In this code block, you are creating objects that represent airports in the United States and providing their name, abbreviation, and the city and state in which they are located. You then export the array to make it available to other parts of your program. This will act as your “staging” data.

      Next, create a dataset for another environment like “development"—the default environment when running npm run serve. To follow the naming convention, create a new file in your terminal with the touch command and name it airports.development.mock.js:

      • touch data/airports.development.mock.js

      In your editor of choice, open this newly created JavaScript file and add the following array of objects:

      data/airports.development.mock.js

      const airports = [
          {
              name: 'Louis Armstrong New Orleans International Airport',
              abbreviation: 'MSY',
              city: 'New Orleans',
              state: 'LA'
          },
          {
              name: 'Denver International Airport',
              abbreviation: 'DEN',
              city: 'Denver',
              state: 'CO'
          },
          {
              name: 'Philadelphia International Airport',
              abbreviation: 'PHL',
              city: 'Philadelphia',
              state: 'PA'
          }
      ]
      
      export default airports
      

      This will act as your "development” data when you run npm run serve.

      Now that you’ve created the mock data for your environments, in the next step, you are going to iterate or loop through that data with the v-for directive and start building out the user interface. This will give you a visual representation of the change when using the different modes.

      Step 3 — Iterating Through Mock Data in App.vue

      Now that you have your mock data, you can test out how useful environments are by iterating through this data in the App.vue component in the src directory.

      First, open up App.vue in your editor of choice.

      Once it is open, delete all of the HTML inside the template tags and remove the import statement in the script section. Also, delete the HelloWorld component in the export object. Some general styles have also been provided to make the data easier to read.

      Add the following highlighted lines to your App.vue file:

      src/App.vue

      <template>
      
      </template>
      
      <script>
      export default {
        name: 'App',
      }
      </script>
      
      <style>
      #app {
        font-family: Avenir, Helvetica, Arial, sans-serif;
        -webkit-font-smoothing: antialiased;
        -moz-osx-font-smoothing: grayscale;
        text-align: center;
        color: #2c3e50;
        margin-top: 60px;
      }
      
      .wrapper {
        display: grid;
        grid-template-columns: 1fr 1fr 1fr;
        grid-column-gap: 1rem;
        max-width: 960px;
        margin: 0 auto;
      }
      
      .airport {
        border: 3px solid;
        border-radius: .5rem;
        padding: 1rem;
      }
      
      .airport p:first-child {
        font-weight: bold;
        font-size: 2.5rem;
        margin: 1rem 0;
      <^>}
      
      .airport p:last-child {
        font-style: italic;
        font-size: .8rem;
      }
      </style>
      

      In this case, CSS Grid is being used to create these cards of airport codes into a grid of three. Notice how this grid is set up in the .wrapper class. The .airport is the card or section that contains each airport code, name, and location.

      Next, import the development mock data that was created earlier. Since this is vanilla JavaScript, you can import it via an import statement. You will also need to register this data with the data property so the Vue template has access to this data.

      Add the following highlighted lines:

      src/App.vue

      ...
      <script>
      import airports from '../data/airports.development.mock'
      
      export default {
        name: 'App',
        data() {
          return {
            airports
          }
        }
      }
      </script>
      ...
      

      Now that the mock data has been imported, you can start using it to build your interface. In the case of this application, iterate through this data with the v-for directive and display it in your template:

      src/App.vue

      <template>
        <div class="wrapper">
          <div v-for="airport in airports" :key="airport.abbreviation" class="airport">
            <p>{{ airport.abbreviation }}</p>
            <p>{{ airport.name }}</p>
            <p>{{ airport.city }}, {{ airport.state }}</p>
          </div>
        </div>
      </template>
      ...
      

      v-for in this case is used to render the list of airports.

      Save and close the file.

      In your terminal, start the development server by running the command:

      Vue CLI will provide you a local address, generally localhost:8080. Visit that addresss in your browser of choice. You will find the data from airports.development.mock.js rendered in your browser:

      Styled cards containing airport data from the development dataset.

      At this point, you created a static mock data layer and loaded it when you executed npm run serve. However, you will notice that if you stop the server (CTRL+C) and start the staging environment, you will have the same result in your browser. In this next step, you are going to tell your app to load a set of data for each environment. To achieve this, you can use a Vue computed property.

      Step 4 — Loading Environment-Specific Data with Computed Properties

      In Vue, computed properties are component functions that must return a value. These functions cannot accept arguments, and are cached by Vue. Computed properties are very useful when you need to perform logic and assign that return value to a property. In this respect, computed properties act similar to data properties as far as the template is concerned.

      In this step, you will use computed properties to use different datasets for the staging and the development environment.

      Start by opening src/App.vue and importing both sets of data:

      src/App.vue

      ...
      <script>
      import DevData from '../data/airports.development.mock'
      import StagingData from '../data/airports.staging.mock'
      
      export default {
        name: 'App',
        ...
      }
      </script>
      ...
      

      If you still have one of the environments running, your data will disappear. That is because you removed the data property that connected your JavaScript mock data to the template.

      Next, create a computed property named airports. The function name is important here because Vue is taking the return value of the function and assigning it to airports for the template to consume. In this computed property, you’ll need to write a bit of logic; an if/else statement that evaluates the Node environment name. To get the value of the Node environment in Vue, you can access it with process.env.NODE_ENV. When you created your Node environments, Vue automatically assigned NODE_ENV to development and staging respectively.

      src/App.vue

      ...
      <script>
      import DevData from '../data/airports.development.mock'
      import StagingData from '../data/airports.staging.mock'
      
      export default {
        name: 'App',
        computed: {
            airports() {
              if (process.env.NODE_ENV === 'development') return DevData
              else return StagingData
            }
        }
      }
      </script>
      ...
      

      Now you are loading each set of data per its respective environment.

      In your terminal, start the local development environment with npm run serve.

      The data will be identical to what it was before.

      Now, start the staging environment by first stopping the server and then executing npm run staging in your terminal window.

      When you visit localhost:8080 in your browser, you will find a different set of data.

      Styled cards containing airport data from the staging dataset.

      Conclusion

      In this tutorial, you worked with different Vue.js environment modes and added environment scripts to your package.json file. You also created mock data for a number of environments and iterated through the data using the v-for directive.

      By using this approach to make a temporary backend, you can focus on the development of your interface and the frontend of your application. You are also not limited to any number of environments or the default environments provided by Vue. It isn’t uncommon to have .env files for four or more environments: development, staging, user acceptance testing (UAT), and production.

      For more information on Vue.js and Vue CLI 3, it’s recommended to read through their documentation. For more tutorials on Vue, check out the Vue Topic Page.



      Source link

      What is an Integrated Development Environment?


      An Integrated Development Environment (IDE) is a software application that allows developers to design, build, test, and debug computer programs within one environment.

      A text editor, terminal, debugging tools, and code snippets are tools that may be included in an IDE. Many IDEs include additional extensions and tools for specific programming languages.

      To learn more about how to use an IDE on the cloud, check out our tutorial, “How To Set Up the code-server Cloud IDE Platform on Ubuntu 20.04.”



      Source link

      How To Set Up a JupyterLab Environment on Ubuntu 18.04


      The author selected the United Nations Foundation to receive a donation as part of the Write for DOnations program.

      Introduction

      JupyterLab is a highly feature-rich UI that makes it easy for users, particularly in the fields of Data Science and AI, to perform their tasks. The JupyterLab environments provide a productivity-focused redesign of Jupyter Notebook. It introduces tools such as a built-in HTML viewer and CSV viewer along with features that unify several discrete features of Jupyter Notebooks onto the same screen.

      In this tutorial, you’ll install and set up JupyterLab on your Ubuntu 18.04 server. You’ll also be configuring your server to be able to connect to the JupyterLab instance remotely from any web browser, securely, using a domain name.

      Prerequisites

      In order to complete this tutorial, you’ll need:

      • An Ubuntu 18.04 server with a non-root user account with sudo privileges using this Initial Server Setup Guide.
      • An installation of the Python Anaconda Distribution on your server. You can use the How To Install the Anaconda Python Distribution on Ubuntu 18.04 tutorial.
      • A registered domain name or sub-domain where you’ve access to edit DNS records. This tutorial will use your_domain throughout. You can purchase domains on Namecheap, get a free domain at Freenom, or register a new domain with any registrar of your choice.
      • The following DNS records set up for your domain:
        • 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.
          This How to Create, Edit, and Delete DNS Records documentation can help you in setting up these records.

      Step 1 — Setting Up Your Password

      In this step you’ll set up a password on your JupyterLab installation. It is important to have a password in place since your instance will be publicly accessible.

      First, make sure your Anaconda environment is activated. As per the prerequisite tutorial the environment is called base.

      To activate the environment, use the following command:

      Your prompt will change in the terminal to reflect the default Anaconda environment base:

      All future commands in this tutorial will be run within the base environment.

      With your Anaconda environment activated, you’re ready to set up a password for JupyterLab on your server.

      First, let’s generate a configuration file for Jupyter:

      • jupyter notebook --generate-config

      You’ll receive the following output:

      Output

      Writing default config to: /home/sammy/.jupyter/jupyter_notebook_config.py

      Both JupyterLab and Jupyter Notebook share the same configuration file.

      Now, use the following command to set a password for accessing your JupyterLab instance remotely:

      • jupyter notebook password

      Jupyter will prompt you to provide a password of your choice:

      Output

      Enter password: Verify password: [NotebookPasswordApp] Wrote hashed password to /home/sammy/.jupyter/jupyter_notebook_config.json

      Jupyter stores the password in a hashed format at /home/sammy/.jupyter/jupyter_notebook_config.json. You’ll need this hashed value in the future.

      Finally, use the cat command on the file generated by the previous command to view the hashed password:

      • cat /home/sammy/.jupyter/jupyter_notebook_config.json

      You’ll receive an output similar to the following:

      /home/sammy/.jupyter/jupyter_notebook_config.json

      {
        "NotebookApp": {
          "password": "sha1:your_hashed_password"
        }
      }
      

      Copy the value in the password key of the JSON and store it temporarily.

      You’ve set up a password for your JupyterLab instance. In the next step you’ll create a Let’s Encrypt certificate for your server.

      Step 2 — Configuring Let’s Encrypt

      In this step, you’ll create a Let’s Encrypt certificate for your domain. This will secure your data when you access your JupyterLab environment from your browser.

      First, you’ll install Certbot to your server. Begin by adding its repository to the apt sources:

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

      On executing the command, you’ll be asked to press ENTER to complete adding the PPA:

      Output

      This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu. Note: Packages are only provided for currently supported Ubuntu releases. More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot Press [ENTER] to continue or Ctrl-c to cancel adding it.

      Press ENTER to continue adding the PPA.

      Once the command has finished executing, refresh the apt sources using the apt update command:

      Next, you’ll install Certbot:

      Before you can start running Certbot to generate certificates for your instance, you’ll allow access on port :80 and port :443 of your server, so that Certbot can use these ports to verify your domain name. Port :80 is checked for http requests to the server while port :443 is used for https requests. Certbot shall be making an http request first and then after obtaining the certficates for your server, it will make an https request, which will be proxied through port :443 to the process listening at :80 port. This will verify the success of your certificate installation.

      First, allow access to port :80:

      You will receive the following output:

      Output

      Rule added Rule added (v6)

      Next, allow access to port :443:

      Output

      Rule added Rule added (v6)

      Finally, run Certbot to generate certificates for your instance using the following command:

      • sudo certbot certonly --standalone

      The standalone flag directs certbot to run a temporary server for the duration of the verfication process.

      It will prompt you for your email:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): your_email

      Enter a working email and press ENTER.

      Next, it will ask you to review and agree to the Terms of Service for Certbot and Let’s Encrypt. Review the terms, type A if you accept, and press ENTER:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A

      It will now prompt you to share your email with the Electronic Frontier Foundation. Type your answer and press ENTER:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y/N

      Finally, you’ll be asked to enter your domain name. Type in your domain name without any protocol specification:

      Output

      Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): your_domain Obtaining a new certificate Performing the following challenges: http-01 challenge for your_domain Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-09-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. 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

      Certbot will perform domain verification and generate certificates and keys for your domain and store them at /etc/letsencrypt/live/your_domain.

      Now that you have set up your Let’s Encrypt certificate, you’ll update your JupyterLab configuration file.

      Step 3 — Configuring JupyterLab

      In this step, you will edit the JupyterLab configuration to make sure it uses the Let’s Encrypt certificate you generated in Step 2. You will also make it accessible using the password you set up in Step 1.

      First, you need to edit the JupyterLab configuration file at /home/sammy/.jupyter/jupyter_notebook_config.py:

      • nano /home/sammy/.jupyter/jupyter_notebook_config.py

      Now, navigate to the line defining the value for c.NotebookApp.certfile and update it as follows:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## The full path to an SSL/TLS certificate file.
      c.NotebookApp.certfile="/etc/letsencrypt/live/your_domain/fullchain.pem"
      ...
      

      Next, find the c.NotebookApp.keyfile variable and set it as shown:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## The full path to a private key file for usage with SSL/TLS.
      c.NotebookApp.keyfile="/etc/letsencrypt/live/your_domain/privkey.pem"
      ...
      

      c.NotebookApp.certfile and c.NotebookApp.keyfile refer to the SSL Certificate, which will be served when you try to access your server remotely using the https protocol.

      Next, navigate to the line defining the c.NotebookApp.ip variable and update as follows:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## The IP address the notebook server will listen on.
      c.NotebookApp.ip = '*'
      ...
      

      c.NotebookApp.ip defines the IPs that can access JupyterLab running your server. You set it to the * wildcard to allow access from any computer you need to access JupyterLab on.

      Next, find the c.NotebookApp.open_browser configuration and update it as follows:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## Whether to open in a browser after starting. The specific browser used is
      #  platform dependent and determined by the python standard library `webbrowser`
      #  module, unless it is overridden using the --browser (NotebookApp.browser)
      #  configuration option.
      c.NotebookApp.open_browser = False
      ...
      

      By default, JupyterLab attempts to automatically initiate a browser session when it starts running. Since we do not have a browser on the remote server, it is necessary to turn this off to avoid errors.

      Next, navigate down to the c.NotebookApp.password variable and change to the following:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## Hashed password to use for web authentication.
      #
      #  To generate, type in a python/IPython shell:
      #
      #    from notebook.auth import passwd; passwd()
      #
      #  The string should be of the form type:salt:hashed-password.
      c.NotebookApp.password = 'your_hashed_password'
      ...
      

      JupyterLab will use this hashed password configuration to check the password you enter for access in your browser.

      Finally, navigate further through the file and update the entry of the c.NotebookApp.port:

      /home/sammy/.jupyter/jupyter_notebook_config.py

      ...
      ## The port the notebook server will listen on.
      c.NotebookApp.port = 9000
      ...
      

      c.NotebookApp.port sets a fixed port for accessing your JupyterLab runtime. This way, you can allow access for only one port from the ufw firewall.

      Once you’re done, save and exit the file.

      Finally, allow traffic on the 9000 port:

      You’ll receive the following output:

      Output

      Rule added Rule added (v6)

      Now that you’ve set all your configuration, you’ll run JupyterLab.

      Step 4 — Running JupyterLab

      In this step, you’ll perform a test run of the JupyterLab instance.

      First, change your current working directory to the user’s home directory:

      Now, modify the access permissions of the certificate files to allow JupyterLab to access them. Change the permissions of the /etc/letsencrypt folder to the following:

      • sudo chmod 750 -R /etc/letsencrypt
      • sudo chown sammy:sammy -R /etc/letsencrypt

      Then, invoke your JupyterLab instance to start using the following command:

      This command accepts several configuration parameters. However, since we have already made these changes in the configuration file, we do not need to provide them here explicitly. You can provide them as arguments to this command to override the values in the configuration file.

      You can now navigate to https://your_domain:9000 to check you receive JupyterLab’s login screen.

      If you log in with the password you set up for JupyterLab in Step 2, you’ll be presented with the JupyterLab interface.

      JupyterLab interface after login

      Finally, press CTRL+C twice to stop the JupyterLab server.

      In the next step, you’ll set up a system service so that the JupyterLab server can be run in the background continuously.

      Step 6 — Setting Up a systemd Service

      In this step, you will create a systemd service that allows JupyterLab to keep running even when the terminal window is exited. You can read more about systemd services and units in this guide on systemd essentials.

      First, you’ll have to create a .service file, using the following command:

      • sudo nano /etc/systemd/system/jupyterlab.service

      Add the following content to the /etc/systemd/system/jupyterlab.service file:

      /etc/systemd/system/jupyterlab.service

      [Unit]
      Description=Jupyter Lab Server
      
      [Service]
      User=sammy
      Group=sammy
      Type=simple
      WorkingDirectory=/home/sammy/
      ExecStart=/home/sammy/anaconda3/bin/jupyter-lab --config=/home/sammy/.jupyter/jupyter_notebook_config.py
      StandardOutput=null
      Restart=always
      RestartSec=10
      
      [Install]
      WantedBy=multi-user.target
      

      Save and exit the editor once you’re done.

      The service file automatically registers itself in the system as a daemon. However, it is not running by default.

      Use the systemctl command to start the service:

      • sudo systemctl start jupyterlab

      This starts the JupyterLab server in the background. You can check if the server has started by using the following command:

      • sudo systemctl status jupyterlab

      You’ll receive the following output:

      Output

      ● jupyterlab.service - Jupyter Lab Server Loaded: loaded (/etc/systemd/system/jupyterlab.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2020-04-26 20:58:29 UTC; 5s ago Main PID: 5654 (jupyter-lab) Tasks: 1 (limit: 1152) CGroup: /system.slice/jupyterlab.service └─5654 /home/sammy/anaconda3/bin/python3.7 /home/sammy/anaconda3/bin/jupyter-lab --config=/home/

      Press Q to exit the service status output.

      You can now head to https://your_domain:9000 in any browser of your choice, provide the password you set up in Step 2, and access the JupyterLab environment running on your server.

      Step 7 — Configuring Renewal of Your Let’s Encrypt Certificate

      In this final step, you will configure your SSL certificates provided by Let’s Encrypt to automatically renew when they expire every 90 days and then restart the server to load the new certificates.

      While Certbot takes care to renew the certificates for your installation, it does not automatically restart the server. To configure the server to restart with new certificates, you will have to provide a renew_hook to the Certbot configuration for your server.

      You’ll need to edit the /etc/letsencrypt/renewal/your_domain.conf file and add a renew_hook to the end of the configuration file.

      First, use the following command to open the /etc/letsencrypt/renewal/your_domain.conf file in an editor:

      • sudo nano /etc/letsencrypt/renewal/your_domain.conf

      Then, at the bottom of this file, add the following line:

      /etc/letsencrypt/renewal/your_domain.conf

      ...
      renew_hook = systemctl reload jupyterlab
      

      Save and exit the file.

      Finally, run a dry-run of the renewal process to verify that your configuration file is valid:

      • sudo certbot renew --dry-run

      If the command runs without any error, your Certbot renewal has been set up successfully and will automatically renew and restart your server when the certificate is near the date of expiry.

      Conclusion

      In this article, you set up a JupyterLab environment on your server and made it accessible remotely. Now you can access your machine learning or data science projects from any browser and rest assured that all exchanges are happening with SSL encryption in place. Along with that, your environment has all the benefits of cloud-based servers.



      Source link