One place for hosting & domains

      Getting Started on the Linode Platform

      Thank you for choosing Linode as your cloud hosting provider! This guide will help you sign up for an account and access Linode’s
      Cloud Manager
      , a browser-based control panel which allows you to manage your Linode virtual servers and services.

      1. Sign Up for an Account
      2. Navigate the Cloud Manager
      3. Create Your First Compute Instance
      4. Create Additional Services
      5. Understand Billing
      6. Explore Linode Guides

      Sign Up for an Account

      First, you need to create a Linode account to start using our services. If you already have a Linode account, you can skip to the next section.

      1. Click the Sign Up button at the top of this page.


        Sign up today
        and receive a $100 credit. This credit will be applied to any valid services used during your first 60 days.
      2. Enter your email address, a unique username, and a strong password. Alternatively, you can sign up using your existing Google or GitHub account.

      3. A confirmation email will be sent to your email address. Click the link to confirm your email and be taken to the next step.

      4. Enter your billing and payment information. A valid credit or debit card must be used when creating an account, though additional payment methods (like Google Pay and PayPal) are available once the account is active.

      Most accounts are activated instantly, but some require manual review prior to activation.


      Sending email: Newly created Linode accounts have restrictions on ports 25, 465, and 587 applied to Compute Instances, which prevent instances from sending email. If you’d like to send email on a Compute Instance, review the
      Running a Mail Server
      guide, then
      open a ticket
      with our Support team.

      Once your account has been created, consider enabling 2FA to prevent unauthorized access. Anyone that has access to your account may be able to delete your services, add new ones, and reset the root password on your Compute Instances to gain access to them. See
      Cloud Manager Security Controls
      for instructions on enabling 2FA. If you are logging in with a third party provider, consider adding 2FA through that provider.

      Cloud Manager
      is the primary gateway to our platform. It enables you to manage your account, view your bills, add services, and much more. Here are some of the main sections you might want to look through:

      • Linodes
        : View a list of your Compute Instances. Clicking on one takes you to its details page, where you can power it on or off, reboot it, resize it, access the console, change its configuration, attach Block Storage volumes, and lots more.

      • Account
        : View your account, billing information, payment methods, and previous invoices. You can also add additional users to your account.

      • Help & Support
        : Search through our guides, find answers on the Community Site, or open a ticket to reach our 24/7 award-winning
        Support Team

      For a full overview of the Cloud Manager and its core features, see the
      Overview of the Cloud Manager

      Create Your First Compute Instance

      Compute Instances (also frequently called Linodes) are virtual machines that can be used for nearly any purpose. Many of our customers use them to host websites and web applications, but they can also be used for development workloads, game servers, big data processing, machine learning, scientific processing, and much more. They come in a few different types, including
      Shared CPU
      Dedicated CPU
      High Memory
      , and
      . Each of these are tailored for certain workloads. See the guides below to learn more about creating a Compute Instance, configuring it after deployment, and securing it.

      Create Additional Services

      In addition to
      Compute Instances
      , Linode offers many other services that empower you to get the most out of cloud computing. Take a look through the list below to determine if any of them might be useful to you.


      • LKE
        (Linode Kubernetes Engine): Managed Kubernetes clusters that simplify container orchestration.
      • Bare Metal
        (Coming soon): Dedicated single-tenant hardware for advanced workloads.


      • Managed Databases
        : Reliable, performant, highly available, and fully managed database clusters to support production database workloads.


      • Block Storage
        : Scalable, high-speed, fault-tolerant, and portable (detachable) storage volumes used to add additional storage to a Compute Instance.
      • Object Storage
        : S3-compatible object storage service that can be used independently of a Compute Instance.
      • Backups
        : Fully managed automatic daily, weekly, and biweekly backups of your Linode Compute Instances.
      • Images
        : Create preconfigured disk images (or upload image files) that can be rapidly deployed to new or existing Compute Instances.


      • NodeBalancers
        : Managed cloud-based load balancing service used with Compute Instances to enable high availability and horizontal scaling.
      • Cloud Firewalls
        : A free cloud-based firewall service that can be used to secure any Compute Instance.
      • DNS Manager
        : A free comprehensive domain and DNS management service for Linode customers.
      • VLANs
        : Private L2 networks to secure traffic between Compute Instances.

      Understand Billing

      Linode services are billed to your primary payment method at the end of each month (or when your accrued charges reach your billing limit). This means you can continuously add, modify, and remove services throughout the month and, after the month is over, you receive an invoice for the hourly usage of each service up to the monthly cap. In affect, billing is post-paid and pro-rated. See the below resources for more billing information and detailed hourly and monthly pricing.

      Keep in mind that charges will accrue for any active service, even if it is powered off or otherwise not in use. This includes Compute Instances that have been powered off as well as any service you might have added to the account but are not using.

      Explore Linode Guides

      Linode offers extensive documentation. This not only includes guides for our core products and services, but general guides on Linux, the command-line, networking, security, version control, databases, and much more. Learn how to deploy a WordPress One-Click App, run a VPN, install a file storage platform, or even host a website using Object Storage. Whatever cloud computing use cases you have in mind, you can likely do it on Linode and our guides are a great place to start.

      Source link

      A Guide to API Formats: The Different Types of APIs

      APIs are what keep software connected. Whether you are looking to link your application to others or you want to have smooth communication between services, APIs help bring multiple pieces of an application together.

      Applications and services can be connected in myriad ways, depending on access limitations and communication protocols. APIs have developed several different approaches for making connections to support modern application architectures.

      In this tutorial, learn about what APIs are, the types of APIs that are available, and the various protocols they can use to communicate.

      What is an API?

      An API — short for Application Programming Interface — defines a set of rules by which applications and services can interact.

      APIs are used in a wide variety of contexts. However, often, when people talk about APIs, they are talking about web APIs. These APIs allow for communication between applications and services using the
      HTTP protocol

      Often, web APIs are used for web application servers and web browsers to communicate. However, you may also see web APIs used for communication between different web servers, or between applications on the same server. You may even see web APIs at work between different services acting as parts of the same application. One example of an API enabling communication between different services of the same application, is Kubernetes. The
      Kubernetes API
      is the linchpin to its powerful orchestration system.

      The Four Main Types of APIs

      APIs come in four different modalities. Each of these covers a different access level or, in the case of web APIs, a different usage.

      Which one of these you use depends on your API’s particular needs. The sections below provide descriptions of each kind of API and they can help you decide which is best for your use case. Each section also provides context and examples to make it easier to see how each API model can fit into different use cases.

      Open APIs

      Open APIs, or public APIs, come with limited or no access restrictions. This essentially allows any developer to make requests to these APIs.

      These APIs may have some limits. A developer may have to register an account to receive an API key, for instance. Additionally, limits may be placed on things like the number of requests in a given time frame.

      But overall, open APIs are distinguished by being intended for widespread external use. They are meant for third-party developers to be able to access and make use of the API as they need.

      An example of open APIs are those provided by
      . After completing a simple registration for an API key, NASA gives you access to numerous open APIs. NASA’s open APIs include everything from Earth observation images to information about the weather on Mars.

      When to Use an Open API?

      Make your API open when you intend it for public consumption. Open APIs are especially useful when you have information or services you want to make available to the general public.

      These APIs are often used for open source projects and for the dissemination of public knowledge, like NASA and other government agencies.

      Partner APIs

      Partner APIs require authorization of some kind to use. They still allow external access, but are not intended for the general public to have access to. Instead, partner APIs are designed for use by pre-approved individuals, teams, or organizations.

      A partner API may allow public access through a paid subscription or it may limit access to developers with a business relationship. Typically, the developer has an API key, as with open APIs, that require registration. But with partner APIs, keys tend to be given out more sparingly and with more access restrictions.

      An example of a partner API is one that allows two companies to work together. Company A may have an application which Company B has agreed to provide services for. Developers at Company A receive API keys which they can use to access Company B’s API. This allows Company A’s application to make use of Company B’s services while keeping access to these services limited.

      When to Use a Partner API?

      Make your API a partner API when it needs to be accessed externally but that access needs to be limited to authorized users. Partner APIs are ideal for business-to-business services or for subscription-based APIs.

      You are likely to see partner APIs in companies that make use of external services for parts of an application’s functionality. Often, this can be a preferred solution compared to developing services in house. It allows companies to integrate features that have been developed by experts elsewhere into their applications. At the same time, it lets the external experts retain control of their services.

      Internal APIs

      Internal APIs, also called private APIs, disallow external access. Instead, these APIs can only be accessed by developers within a company or even within the particular application to which the API belongs.

      These APIs are the most limited. APIs are incredibly useful in defining communication between applications and services, and this even applies when communication is within a single organization.

      A simple example of an internal API use case is a company that has two applications for selling items. One application allows customers to purchase items directly; the other allows sales personnel to process sales. Both applications need access to the inventory. The company could have both applications independently access the inventory database. However, doing so would likely lead to more difficult and inconsistent maintenance.

      So, instead, the company has an internal API for managing inventory. Both the customer-facing and sales-personnel applications can access this API to view and update inventory. Updates to each application can be made independently, as long as each adheres to the rules of the API.

      When to Use an Internal API?

      Make your API internal when you want to restrict access as much as possible. Internal APIs are designed to be private, with only applications and services within your organization having access. An internal API can even be used when different parts of an application need to communicate.

      These APIs are common within enterprise organizations. When applications scale, it helps to define APIs for managing underlying logic. Take the example above, where business logic can be developed and maintained in the customer-facing and sales-personnel applications. This can be done without concern for the impact to the underlying data storage and retrieval tasks, since those are housed in the internal API.

      Composite APIs

      Composite APIs allow for requests to be bundled or chained together, which, in turn, allows developers to receive single responses for request collections.

      These APIs are useful for reducing server load and network traffic when you expect frequent requests to multiple API endpoints. Calls get made less frequently, resulting in reductions to server processing time and the number of requests across the network.

      This makes composite APIs exceptionally effective for microservices. Often, applications built on microservices have to compile information from multiple sources. Having composite APIs that do this makes for more efficient applications.

      To give an example of a composite API in action, think of an online ordering form. When the user completes and submits the form, the application often has to register the user, check and update inventory, and send a confirmation notification. A composite API allows all of these tasks to be handled simultaneously, in a single call.

      When to Use a Composite API?

      Make use of a composite API when your application exposes endpoints that are likely to be called in groups or in quick succession. This is often the case with microservices, where requests and responses frequently need to be combined.

      This type of API can be especially useful when your
      microservice application
      needs to communicate with users’ web browsers. Here, you want to optimize network traffic to reduce load times and improve user experience. You also want to reduce your server load to make your application scalable for a larger number of users.

      What are the Different API Protocol Types?

      Every API uses a particular protocol. An API’s protocol defines the rules for how it can communicate. These rules make explicit the kinds of requests that can be made, what the API’s responses look like, and what kinds of data the API can send and receive.

      There are three main protocols used by web APIs.

      • REST. Short for Representational State Transfer, REST implements stateless APIs with uniform interfaces using HTTP. REST is actually more of a set of architectural principles for APIs than a protocol proper. You can use the
        Flask Python framework
        to build your own REST API.

      • SOAP. The Simple Object Access Protocol uses XML for requests and responses and maintains strict definitions for messages. SOAP is highly adaptable, designed to be neutral, and applicable in many contexts, not just for web APIs. It can even be used in conjunction with REST principles.

      • RPC. Simpler than both REST and SOAP, the Remote Procedural Call protocol focuses on actions taken on a server. This is in contrast to both REST and SOAP, which tend to focus on server resources. RPC works primarily on running processes. Often, RPC APIs execute scripts on the server.


      This guide has walked you through the basics of APIs, explaining the different categories they fit into and the contexts they are used in. The four main types of APIs are open, partner, internal, and composite. The guide also covered the protocols web APIs use to send and receive messages. These API protocols are REST, SOAP, and RPC. You now have a strong foundation for entering into the world of web APIs. It is a wide and fast-moving world.

      Source link

      Using Redis Transaction Blocks

      Redis is an open-source, in-memory database used for caching, messaging, and other storage tasks that benefit from fast execution and low latency. The Redis database supports a high degree of control over parallel executions that allow you to fine-tune its performance.

      This guide walks you through using Redis’s transaction blocks. Transaction blocks group Redis commands and execute them as single units. Doing so guarantees uninterrupted sequential execution of each set of commands. This ensures that all of the commands in a transaction block are executed, even in highly parallel environments.

      Before You Begin

      1. Familiarize yourself with our
        Getting Started with Linode
        guide and complete the steps for setting your Linode’s hostname and timezone.

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

      3. Update your system.

        • On Debian and Ubuntu, use the following command:

          sudo apt update && sudo apt upgrade
        • On AlmaLinux, CentOS (8 or later), or Fedora, use the following command:

          sudo dnf upgrade
      4. Follow the instructions in our
        How to Install and Configure Redis
        guide to installing a Redis server and command-line interface (CLI). Be sure to use the drop-down menu at the top of that page to select your Linux distribution and get the appropriate steps.


      The steps written in this guide are for non-root users. Commands that require elevated privileges are prefixed with sudo. If you’re not familiar with the sudo command, see the
      Linux Users and Groups

      What Are Redis Transactions?

      Redis Transactions are a group of commands that are executed collectively and sequentially. The benefits of executing commands as transaction blocks are to ensure the following:

      • The sequence of commands is not interrupted, even by another Redis client
      • The commands are executed as an atomic unit and the entire transaction block is processed collectively

      Transactions are especially useful in environments with numerous clients, and where clients are making frequent transactions in parallel. Redis’s transaction blocks ensure that a given set of commands executes as a unit and in a predetermined order.

      Transaction Blocks vs. Pipelines

      Redis pipelining is another method used to optimize command execution in a highly parallel network. Pipelining in Redis allows clients to queue a series of commands and send them to the server simultaneously, rather than in multiple round trips.

      It may seem like transaction blocks and pipelining serve similar purposes. However, each has a distinct goal and acts to optimize command execution in very different ways from the other. Some of the differences are:

      • Pipelining is concerned primarily with network efficiency. It reduces the round-trip time for a series of commands by submitting them all in one request, rather than a series of requests each with its own response.

        Pipelining is useful for reducing latency and increasing the feasible number of operations per second.

      • Transactions are concerned with the integrity of a group of commands. They ensure that the entirety of a designated group of commands gets executed sequentially and without interruption. This is in contrast to pipelines that may execute requests in alternation with requests sent from other clients.

        Transaction blocks are useful when you need to guarantee a collection of commands is processed as a unit and the commands are executed sequentially.

      How to Run a Transaction Block

      To start a transaction in Redis, use the following command in the Redis CLI:


      The MULTI command begins a new transaction block. Any subsequent commands you enter are queued in sequence. To end the queuing of commands and complete the transaction block, use the following command:


      The commands displayed below include a complete example of creating a transaction block with the MULTI and EXEC commands. It starts with the MULTI command to initiate a transaction block. Then it creates a new key with a value of 10 and increments that key’s value by one. The key is then reset to 8 and again increments the value by one. Finally, the EXEC command completes the block and executes the transaction.

      SET the_key 10
      INCR the_key
      SET the_key 8
      INCR the_key
      GET the_key

      Notice that, for each command within the block (between MULTI and EXEC), the client responds with QUEUED. Once you send the EXEC command, the server provides an appropriate response for each command within the transaction.

      1) OK
      2) (integer) 11
      3) OK
      4) (integer) 9
      5) "9"

      How to Handle Errors in a Transaction Block

      When working with Redis transaction blocks, there are two kinds of errors that you may encounter. Based on when they occur, the errors can be categorized as follows:

      • Errors before the EXEC command:

        These include errors related to syntax or related to server restrictions, like maximum memory. Although you can continue queuing commands after receiving one of these errors, the transaction block subsequently fails when you run EXEC.

        For example, the transaction below includes a typo for the GET command:

        SET new_key "alpha"
        GRT new_key
        (error) ERR unknown command `GRT`, with args beginning with: `new_key`,

        Disregarding the error and attempting to execute the transaction results in an error.

        (error) EXECABORT Transaction discarded because of previous errors.

        For this reason, you should cancel any transaction blocks that encounter errors during queuing. See the next section —
        How to Cancel a Transaction Block
        — for instructions on how to do so.

      • Errors after the EXEC command:

        These are errors returned by the server in response to individual commands in the transaction. For example, you might receive such an error due to mismatched types:

        SET new_key "beta"
        LPOP new_key
        1) OK
        2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

        Notice that the first command was executed successfully, which you can further verify using the GET command:

        GET new_key

      How to Cancel a Transaction Block

      A transaction can be canceled at any time before the EXEC command. To do so, use the DISCARD command.

      The example below demonstrates that the key, another_key remains unchanged from its pre-transaction value:

      SET another_key "gamma"
      SET another_key 2
      INCR another_key
      GET another_key

      As mentioned above, the ability to cancel an in-progress transaction becomes especially handy if you encounter an error while queuing commands for a transaction.


      Redis transaction execute a collection of commands and ensure that the command execution is not interrupted by another client. This guide covered creating transaction blocks, understanding common transaction errors, and canceling in-progress transactions.

      You can learn more about Redis and how to get the most out of your Redis databases through our other guides in this series. These guides cover everything from
      connecting to a remote Redis server
      to working with the
      hash data type

      More Information

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

      Source link