One place for hosting & domains

      Manager

      How To Install and Use the Yarn Package Manager for Node.js


      Introduction

      Yarn is a package manager for Node.js that focuses on speed, security, and consistency. It was originally created to address some issues with the popular NPM package manager. Though the two package managers have since converged in terms of performance and features, Yarn remains popular, especially in the world of React development.

      Some of the unique features of Yarn are:

      • A per-project caching mechanism, that can greatly speed up subsequent installs and builds
      • Consistent, deterministic installs that guarantee the structure of installed libraries are always the same
      • Checksum testing of all packages to verify their integrity
      • “Workspaces”, which facilitate using Yarn in a monorepo (multiple projects developed in a single source code repository)

      In this tutorial you will install Yarn globally, add Yarn to a specific project, and learn some basic Yarn commands.

      Prerequisites

      Before installing and using the Yarn package manager, you will need to have Node.js installed. To see if you already have Node.js installed, type the following command into your local command line terminal:

      If you see a version number, such as v12.16.3 printed, you have Node.js installed. If you get a command not found error (or similar phrasing), please install Node.js before continuing.

      To install Node.js, follow our tutorial for Ubuntu, Debian, CentOS, or macOS.

      Once you have Node.js installed, proceed to Step 1 to install the Yarn package manager.

      Step 1 — Installing Yarn Globally

      Yarn has a unique way of installing and running itself in your JavaScript projects. First you install the yarn command globally, then you use the global yarn command to install a specific local version of Yarn into your project directory. This is necessary to ensure that everybody working on a project (and all of the project’s automated testing and deployment tooling) is running the exact same version of yarn, to avoid inconsistent behaviors and results.

      The Yarn maintainers recommend installing Yarn globally by using the NPM package manager, which is included by default with all Node.js installations. Use the -g flag with npm install to do this:

      After the package installs, have the yarn command print its own version number. This will let you verify it was installed properly:

      Output

      1.22.11

      Now that you have the yarn command installed globally, you can use it to install Yarn into a specific JavaScript project.

      Step 2 — Installing Yarn in Your Project

      If you are using Yarn to work with an existing Yarn-based project, you can skip this step. The project should already be set up with a local version of Yarn and all the configuration files necessary to use it.

      If you are setting up a new project of your own, you’ll want to configure a project-specific version of Yarn now.

      First, navigate to your project directory:

      If you don’t have a project directory, you can make a new one with mkdir and then move into it:

      • mkdir my-project
      • cd my-project

      Now use the yarn set command to set the version to berry:

      This will download the current, actively developed version of Yarn – berry – save it to a .yarn/releases/ directory in your project, and set up a .yarnrc.yml configuration file as well:

      Output

      Resolving berry to a url... Downloading https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js... Saving it into /home/sammy/my-project/.yarn/releases/yarn-berry.cjs... Updating /home/sammy/my-project/.yarnrc.yml... Done!

      Now try the yarn --version command again:

      Output

      3.0.0

      You’ll see the version is 3.0.0 or higher. This is the latest release of Yarn.

      Note: if you cd out of your project directory and run yarn --version again, you’ll once again get the global Yarn’s version number, 1.22.11 in this case. Every time you run yarn, you are using the globally installed version of the command. The global yarn command first checks to see if it’s in a Yarn project directory with a .yarnrc.yml file, and if it is, it hands the command off to the project-specific version of Yarn configured in the project’s yarnPath setting.

      Your project is now set up with a project-specific version of Yarn. Next we’ll look at a few commonly used yarn commands to get started with.

      Using Yarn

      Yarn has many subcommands, but you only need a few to get started. Let’s look at the first subcommands you’ll want to use.

      Getting Help

      When starting out with any new tool, it’s useful to learn how to access its online help. In Yarn the --help flag can be added to any command to get more information:

      This will print out overall help for the yarn command. To get more specific information about a subcommand, add --help after the subcommand:

      This would print out details on how to use the yarn install command.

      Starting a New Yarn Project

      If you’re starting a project from scratch, use the init subcommand to create the Yarn-specific files you’ll need:

      This will add a package.json configuration file and a yarn.lock file to your directory. The package.json contains configuration and your list of module dependencies. The yarn.lock file locks those dependencies to specific versions, making sure that the dependency tree is always consistent.

      Installing all of a Project’s Dependencies

      To download and install all the dependencies in an existing Yarn-based project, use the install subcommand:

      This will download and install the modules you need to get started.

      Adding a New Dependency to a Project

      Use the add subcommand to add new dependencies to a project:

      This will download the module, install it, and update your package.json and yarn.lock files.

      Updating Your .gitignore File for Yarn

      Yarn stores files in a .yarn folder inside your project directory. Some of these files should be checked into version control and others should be ignored. The basic .gitignore configuration for Yarn follows:

      .gitignore

      .yarn/*
      !.yarn/patches
      !.yarn/releases
      !.yarn/plugins
      !.yarn/sdks
      !.yarn/versions
      .pnp.*
      

      This ignores the entire .yarn directory, and then adds in some exceptions for important folders, including the releases directory which contains your project-specific version of Yarn.

      For more details on how to configure Git and Yarn, please refer to the official Yarn documentation on .gitignore.

      Conclusion

      In this tutorial you installed Yarn and learned about a few yarn subcommands. For more information on using Yarn, take a look at the official Yarn CLI documentation.

      For more general Node.js and JavaScript help, please visit our Node.js and JavaScript tag pages, where you’ll find relevant tutorials, tech talks, and community Q&A.



      Source link

      How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager


      Introduction

      Helm is a package manager for Kubernetes that allows developers and operators to more easily configure and deploy applications on Kubernetes clusters.

      In this tutorial, you will set up Helm 3 and use it to install, reconfigure, rollback, and delete an instance of the Kubernetes Dashboard application. The dashboard is an official web-based Kubernetes GUI.

      For a conceptual overview of Helm and its packaging ecosystem, please read our article, An Introduction to Helm.

      Prerequisites

      For this tutorial you will need:

      • A Kubernetes cluster with role-based access control (RBAC) enabled. Helm 3.1 supports clusters from versions 1.14 to 1.17. For further information check the Helm releases page.
      • The kubectl command-line tool installed on your local machine, configured to connect to your cluster. You can read more about installing kubectl in the official documentation.

        You can test your connectivity with the following command:

        If you see no errors, you’re connected to the cluster. If you access multiple clusters with kubectl, be sure to verify that you’ve selected the correct cluster context:

        • kubectl config get-contexts

        Output

        CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-fra1-helm3-example do-fra1-helm3-example do-fra1-helm3-example-admin

        In this example the asterisk (*) indicates that we are connected to the do-fra1-helm3-example cluster. To switch clusters run:

        • kubectl config use-context context-name

      When you are connected to the correct cluster, continue to Step 1 to begin installing Helm.

      Step 1 — Installing Helm

      First, you’ll install the helm command-line utility on your local machine. Helm provides a script that handles the installation process on MacOS, Windows, or Linux.

      Change to a writable directory and download the script from Helm’s GitHub repository:

      • cd /tmp
      • curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

      Make the script executable with chmod:

      You can use your favorite text editor to open the script and inspect it to make sure it’s safe. When you are satisfied, run it:

      You may be prompted for your password. Provide it and press ENTER to continue.

      The output will look like this:

      Output

      Downloading https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz Preparing to install helm into /usr/local/bin helm installed into /usr/local/bin/helm

      Now that you’ve got Helm installed, you’re ready to use Helm to install your first chart.

      Step 2 — Installing a Helm Chart

      Helm software packages are called charts. There is a curated chart repository called stable, mostly consisting of common charts, which you can see in their GitHub repo. Helm does not come preconfigured for it, so you’ll need to manually add it. Then, as an example, you are going to install the Kubernetes Dashboard.

      Add the stable repo by running:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com

      The output will be:

      Output

      "stable" has been added to your repositories

      Then, use helm to install the kubernetes-dashboard package from the stable repo:

      • helm install dashboard-demo stable/kubernetes-dashboard --set rbac.clusterAdminRole=true

      The --set parameter lets you to customize chart variables, which the chart exposes to allow you to customize its configuration. Here, you set the rbac.clusterAdminRole variable to true to grant the Kubernetes Dashboard access to your whole cluster.

      The output will look like:

      Output

      NAME: dashboard-demo LAST DEPLOYED: Tue Mar 31 15:04:19 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ...

      Notice the NAME line, highlighted in the above example output. In this case, you specified the name dashboard-demo. This is the name of the release. A Helm release is a single deployment of one chart with a specific configuration. You can deploy multiple releases of the same chart, each with its own configuration.

      You can list all the releases in the cluster:

      The output will be similar to this:

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dashboard-demo default 1 2020-03-31 15:04:19.324774799 +0000 UTC deployed kubernetes-dashboard-1.10.1 1.10.1

      You can now use kubectl to verify that a new service has been deployed on the cluster:

      The output will look like this:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP 10.245.115.214 <none> 443/TCP 4m44s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 19m

      Notice that by default, the service name corresponding to the release is a combination of the Helm release name and the chart name.

      Now that you’ve deployed the application, you’ll use Helm to change its configuration and update the deployment.

      Step 3 — Updating a Release

      The helm upgrade command can be used to upgrade a release with a new or updated chart, or update its configuration options (variables).

      You’re going to make a simple change to the dashboard-demo release to demonstrate the update and rollback process: you’ll update the name of the dashboard service to just kubernetes-dashboard, instead of dashboard-demo-kubernetes-dashboard.

      The kubernetes-dashboard chart provides a fullnameOverride configuration option to control the service name. To rename the release, run helm upgrade with this option set:

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="kubernetes-dashboard" --reuse-values

      By passing in the --reuse-values argument, you make sure that chart variables you’ve previously set do not get reset by the upgrade process.

      You’ll see output similar to the initial helm install step.

      Check if your Kubernetes services reflect the updated values:

      The output will look like the following:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 38m kubernetes-dashboard ClusterIP 10.245.49.157 <none> 443/TCP 8s

      Notice that the service name has been updated to the new value.

      Note: At this point you may want to actually load the Kubernetes Dashboard in your browser and check it out. To do so, first run the following command:

      This creates a proxy that lets you access remote cluster resources from your local computer. Based on the previous instructions, your dashboard service is named kubernetes-dashboard and it’s running in the default namespace. You may now access the dashboard at the following URL:

      http://localhost:8001/api/v1/namespaces/default/services/https:kubernetes-dashboard:https/proxy/
      

      Instructions for actually using the dashboard are out of scope for this tutorial, but you can read the official Kubernetes Dashboard docs for more information.

      Next, you’ll have a look at Helm’s ability to roll back and delete releases.

      Step 4 — Rolling Back and Deleting a Release

      When you updated the dashboard-demo release in the previous step, you created a second revision of the release. Helm retains all the details of previous releases in case you need to roll back to a prior configuration or chart.

      Use helm list to inspect the release again:

      You’ll see the following output:

      Output

      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      The REVISION column tells you that this is now the second revision.

      Use helm rollback to roll back to the first revision:

      • helm rollback dashboard-demo 1

      You should see the following output, indicating that the rollback succeeded:

      Output

      Rollback was a success! Happy Helming!

      At this point, if you run kubectl get services again, you will notice that the service name has changed back to its previous value. Helm has re-deployed the application with revision 1’s configuration.

      Helm releases can be deleted with the helm delete command:

      • helm delete dashboard-demo

      The output will be:

      Output

      release "dashboard-demo" uninstalled

      You can try listing Helm releases:

      You’ll see that there are none:

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION

      Now the release has been truly deleted, and you can reuse the release name.

      Conclusion

      In this tutorial, you installed the helm command-line tool and explored installing, upgrading, rolling back, and deleting Helm charts and releases by managing the kubernetes-dashboard chart.

      For more information about Helm and Helm charts, please see the official Helm documentation.



      Source link

      An Overview of the Linode Cloud Manager


      Updated by Linode

      Contributed by
      Linode

      The Linode Cloud Manager provides a user-friendly interface to manage your infrastructure, user accounts, billing and payments, and to open and track support tickets. You can easily create Linode instances, managed Kubernetes clusters, add backups to your Linodes, deploy One-Click Apps, track event notifications, create Object Storage buckets, and more. The Cloud Manager is implemented solely atop our public APIv4, which gives you access to all our latest products and services.

      In this Guide

      This guide provides an overview of the features and services available in Linode’s Cloud Manager. Some of the topics that will be discussed are:

      • An introduction to each section of the Cloud Manager, including links to related guides throughout our documentation library.
      • The location of commonly used Cloud Manager features.
      • Settings that might make your overall Cloud Manager experience better

      Linodes

      The Linodes section of Cloud Manager allows you to create and manage your Linodes. Each Linode instance in Cloud Manager includes:

      • Summary information about your Linode, like CPU usage, IPv4 and IPv6 traffic, and Disk IO
      • Access to any of your Linode’s attached Volumes and the ability to create a Volume
      • Networking information and features, including the ability to add IPv4 and IPv6 addresses, IP transfer and IP sharing
      • The ability to resize your Linode, boot your Linode into Rescue Mode, and rebuild your Linode
      • Access to Linode’s Backup service
      • An Activity Feed that displays any relevant events related to this Linode
      • Settings that allow you to update your Linode’s label, reset your Linode’s root password, manage system usage email notifications, manage Watchdog (Linode’s automatic reboot feature), and delete your Linode
      • An area to manage and create disks and configuration profiles
      • Cross data center migrations

      Find Your Disks

      You can find your Linode’s disks in the Disks/Configs tab of the Linode’s detail page.

      1. Click the Linodes link in the sidebar menu and select the Linode whose disks you’d like to see.

      2. Then click the Disks/Configs tab. The disks are located in the Disks panel. Here you can add a disk, or for each individual disk, you can click the more options ellipses to get a drop down menu which will allow you to choose options such as Rename, Resize, Imagize, Clone, and Delete.

        Location of Cloud Manager Disks

      Reboot Your Linode

      You can reboot a Linode from two places within the Cloud manager.

      1. From your Linodes listing page, click the More Options Ellipses and select Reboot.

        Cloud Manager Linode List Menu Reboot Option

        If you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

        Cloud Manager Reboot Detail Panel

      2. You can also reboot your Linode from within any Linode details page by clicking on the Status Icon. A drop down menu will appear, select Reboot.

        Cloud Manager Linode Detail Menu Reboot Option

        Again, if you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

      Delete a Public IP Address

      You can delete a public IP addresses within the Cloud Manager from the Networking tab in a Linode’s details page.

      1. Click Linodes from the sidebar menu.

      2. Choose the Linode you wish to modify to enter the Linode detail screen. Then, click on the Networking tab. Your IPv4 and IPv6 addresses will be listed here.

      3. Next to the public IPv4 address you wish to delete, click on the more options ellipses. Select the option to Delete IP from the drop down menu.

        Cloud Manager Delete a Public IP Address

      4. A confirmation popup will appear where you can confirm the operation.

        Note

        You must have at least one public IP on a Linode. If you attempt to delete the last public IP on a Linode you will receive an error message after you confirm the deletion.

      Volumes

      The Volumes section of Cloud Manager gives you access to Linode’s Block Storage service. To learn how to create, and manage Block Storage volumes using Cloud Manager, see our How to Use Block Storage with Your Linode guide.

      Object Storage

      The Object Storage section of Cloud Manager gives you access to Linode’s Object Storage service which is a globally-available, S3-compatible method for storing and accessing data.

      To learn how to begin using Object Storage, view our How to Use Linode Object Storage guide. To access all available Object Storage guides, see the Object Storage section of our documentation site.

      NodeBalancers

      Linode’s NodeBalancers service provides load balancing for your applications and services ensuring that they are highly available for users. To learn how to get started with NodeBalancers using Cloud Manager, see our Getting Started with NodeBalancers guide.

      Domains (DNS Manager)

      The DNS Manager allows you to control and manage your domains. You can access the DNS Manager by navigating to the Domains link in the Cloud Manager’s sidebar.

      Cloud Manager Domains

      For more information on Cloud Manager’s DNS Manager, see the following guides:

      Zone Files

      The Cloud Manager automatically ensures that your Domain’s zone file does not contain any errors when a Domain Record is created or updated.

      Note

      This Cloud Manager and API v4 functionality is currently under active development.
      • When creating a Zone File for a Domain, the Linode API v4 checks for any errors that may exist. If an error is found, the Cloud Manager will respond with the corresponding error. This means that the Cloud Manager will not allow you to create an invalid zone file.

      • Once your Domain and corresponding Zone File is created, you can use the dig command to further verify that each domain record contains the information you expect. It will take a few moments before a newly created domain record will show up when issuing the dig command.

        dig example.com
        dig example.com MX
        

        See the Use dig to Perform Manual DNS Queries guide for more details on the dig command.

      Longview

      The Longview section of Cloud Manager gives you access to Linode’s system data graphing service. It tracks metrics for CPU, memory, and network bandwidth, both aggregate and per-process, and it provides real-time graphs that can help expose performance problems. The Longview service offers both free and paid plan tiers.

      To get started using Longview, see the Understanding Linode Longview guide.

      One-Click Apps

      The One-Click Apps section of Cloud Manager gives you access to apps that make it easy to deploy and configure software on a Linode. Some popular One-Click Apps are WordPress, Minecraft, and GitLab. We are actively adding new and useful One-Click apps. When a One-Click App is deployed, a new Linode is created and the appropriate software is installed with the configurations you provide.

      See How to Use Linode’s One-Click Apps to get started using One-Click Apps in Cloud Manager.

      Kubernetes

      The Kubernetes section of Cloud Manager gives you access to our managed Kubernetes service, the Linode Kubernetes Engine (LKE). LKE is a fully-managed container orchestration engine for deploying and managing containerized applications and workloads. LKE combines Linode’s ease of use and simple pricing with the infrastructure efficiency of Kubernetes.

      To get started using LKE, see our Tutorial for Deploying and Managing a Cluster with Linode Kubernetes Engine.

      StackScripts

      StackScripts provide Linode users with the ability to automate the deployment of custom systems on top of our default Linux distribution images. StackScripts are usually Bash scripts, stored in the Linode Cloud Manager, and can be accessed when you deploy a Linode. Linodes deployed with a StackScript run the script as part of the first boot process.

      To get started using StackScripts in Cloud Manager, see the Automate Deployment with StackScripts guide.

      Images

      The Images section of Cloud Manager gives you access to Linode Images which allow you to take snapshots of your disks, and then deploy them to any Linode under your account. This can be useful for bootstrapping a master image for a large deployment, or retaining a disk for a configuration that you may not need running, but wish to return to in the future.

      To get started using Images with Cloud Manager, see Linode Images.

      Account (Management and Billing)

      The Account section of Cloud Manager allows you to manage your account’s billing information and users, and to configure various account-wide settings.

      You can manage the following account and billing settings in the Account section of Cloud Manager:

      Find Credit Remaining

      To find the amount of available credit that you have:

      1. Click on the Account link from the sidebar menu.

      2. On the right hand side of the screen you’ll see the Billing Information section. If you have credit stored on your account, it’ll appear in green under the Current Balance field.

      Credits Listed under Current Balance

      Printing an Invoice

      You can download a printable PDF of your billing invoice from your list of invoices or from within an individual invoice.

      1. Navigate to your Account by clicking on Account in the sidebar.

      2. Click on the Recent Invoices menu item in the Billing section. This will expand to show you a list of your recent invoices. Each invoice has a Download PDF link next to it.

        Cloud Manager Download Invoice from Recent Invoices List

      3. You can also click on any invoice to view it within the Cloud Manager. At the top of the invoice there is a Download PDF button.

        Cloud Manager Download Invoice from Detail View

      Password Management

      The Cloud Manager does not support forcing password expirations. Forcing password resets on a schedule is bad practice from a security perspective. Current security research indicates that forced password changes do more harm than good. If you want to force password resets for users of your Linode account, we recommend using a password manager for this purpose.

      Linode’s Cloud Manager and API v4 allow you to create tags to help organize and group your Linode resources. Tags can be applied to Linodes, Block Storage Volumes, NodeBalancers, and Domains. See the Tags and Groups guide to learn how to create, apply, and search for tags.

      Events and Activity Feeds

      Tasks performed using the Linode Cloud Manager or other account specific tools like Linode’s CLI or API will be logged to an individual Linode’s activity feed, or on your account’s Events Page. The events and activity pages are user accessible logs, or histories of events taking place on your account. They contain details regarding the most notable events affecting your Linodes, like reboots, shutdowns, migrations, and more.

      For more details, see the Understanding the Cloud Manager Events and Activity Feeds guide.

      My Profile

      The My Profile section of Cloud Manager provides access to various settings related to your Linode account’s profile. This area of Cloud Manager contains access to the following features and settings:

      API Keys / API Tokens

      API Tokens (personal access tokens) are used in token-based authentication to provide users or programming scripts with different levels of access to your Linode account’s resources and services via the Linode API v4. You can create and manage your API tokens using the Cloud Manager.

      1. To generate a new personal access token, navigate to your profile by clicking on your username and select My Profile from the drop down menu. Then click on the API Tokens tab.

        Cloud Manager Add a Personal Access Token

      2. Click Add a Personal Access Token. A panel will display allowing you to give this token a label and choose the access rights you want users authenticated with the new token to have.

        Cloud Manager Add a Personal Access Token Panel

      3. When you have finished, click Submit to generate a new Personal Access Token. Copy the token and save it to a secure location before closing the popup. You will not be able to view this token through the Cloud Manager after closing the popup.

      OAuth Apps

      The Cloud Manager supports the OAuth 2 authorization protocol. OAuth 2 allows a user to safely grant a third-party app permission to act on their behalf. This means that a user could authorize an app to access data and / or make changes to their Linode account and services that are exposed by the Linode APIv4. For example, an app could create or destroy Linodes, manage a NodeBalancer, or alter a domain.

      To learn how to get started with OAuth Apps see the How To Create an OAuth App with the Linode Python API Library guide. For details on the Linode API v4’s OAuth workflow see the Linode API v4 documentation.

      Manage Email Event Notifications

      Email event notifications alert you when new events such as booting, shutting down, or updates to a Linode occur on your account. You can enable or disable email event notifications using the Cloud Manager.

      You can manage your event notifications in the Settings tab from the My Profile section of the Cloud Manager.

      Cloud Manager Notification Settings

      User Interface Enhancements

      Compact Mode and Dark Mode

      Cloud Manager provides three different UI themes that you can toggle on and off depending on your preference. By default, Normal mode will be selected. You can also choose Compact Mode which compresses any extra screen space and allows more information to be displayed on the screen. This setting is located at the bottom left hand corner of the screen when the gear icon is clicked. This is also where you can toggle on Dark Mode, which changes your UI’s color scheme. Light mode is selected by default.

      Compact Mode Enabled

      Accessibility

      The Linode Cloud Manager has been built with accessibility in mind. Currently, the Cloud Manager is actively being developed to achieve WCAG 2.0 Level AA.

      We have received a lot of helpful feedback from our users regarding accessibility. While we have addressed a lot of your feedback, this is still a work in progress and will be iterated upon with time. Please contact [email protected] with any comments or requests regarding accessibility.

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



      Source link