Forem: Jake Malachowski

How to Build an Anycast Network

Jake Malachowski — Mon, 25 Oct 2021 20:54:28 +0000

When you type a URL into your address bar, your browser performs a DNS lookup to resolve the human-readable domain name to an IP address necessary for networking software, for example 216.24.57.1. Armed with that IP, how do the packets comprising the request actually get from your local machine to a server somewhere in the world capable of handling that request? How do you ensure those packets route to the server that can handle the request most efficiently?

Serving traffic as efficiently as possible, regardless of where it originates, is a critical requirement at Render. One answer to this challenge is to deploy a global fleet of servers to create an anycast network. What is an anycast network? What is it good for? How can you build your own? This post will answer all of these questions, but we’ll first need some background on the building blocks of global networking.

A Brief Overview of the Internet

The path that an HTTP request takes between autonomous systems communicating via BGP.

The Internet is the greatest decentralized network in the history of mankind. There is no central authority that controls who is allowed to connect or how you can use it. How do we manage billions of internet-connected devices without any single organization in charge of maintaining the system? This is accomplished through the coordination of many independent entities called Autonomous Systems (AS). ASs are the networking backbone of the internet. These entities, often managed by ISPs or large technology organizations, are responsible for handling traffic for the IP addresses they manage and advertising the paths to all other IP prefixes of which they are aware. Connections between ASs, also known as peers, are established through the manual configuration of connections between routers.

Once a connection has been established, ASs use the Border Gateway Protocol (BGP) to coordinate with each other. BGP carries the information necessary for ASs to determine the optimal path to a target. Many factors can be used to define "optimal", but the most common heuristic used is choosing the path with the fewest number of "hops" between ASs before reaching the destination. Each AS will store the best path for all IP prefixes in its routing table. When a route is added or removed, the AS will update its routing table, if necessary, and advertise the change to its peers so they can do the same. Each peer sends keep-alive messages to each other at regular intervals. If an AS does not send a keep-alive message before the configured timeout, the peer will stop advertising the AS as a reachable hop and packets will use a different path to reach the target if it exists.

What is Anycast?

An anycast network is two or more servers advertising the same IP address from different locations. Why would we want to do this?

Serving traffic from a single location often lacks the redundancy required for critical or latency-sensitive applications that serve users around the world. In the worst case of a global round-trip request, you can expect 300 ms of latency just in transit time. This doesn't account for the time it takes the server to process the request. Chain a few of these requests together and you're looking at a very sluggish application and a frustrating user experience. For applications that require high availability and low latency, you will want an architecture that has the following characteristics:

Globally distributed
Automatically routes traffic to the optimal server
Tolerates failures of individual servers

We can leverage the advanced routing capabilities of BGP to create a fault-tolerant, low-latency system by building an anycast network. By advertising an IP from many servers around the world, we can rely on BGP to route users' requests to the nearest Point of Presence (PoP) -- or server, in other words -- that advertises the IP. When one of those PoPs fails, it will stop sending keep-alive messages to its peers, connected ASs will stop advertising the path, and traffic will reroute to a healthy PoP.

How Render Uses Anycast

How Render uses anycast to route traffic to the proper origin

When you deploy a web service or static site on Render, you always get a subdomain of onrender.com that makes your service accessible from the internet. In many cases, users want to use a custom domain that they own instead of an onrender.com subdomain. Users can create a DNS A record for their custom domain that points to an IP address provided by Render.

Render strives to create the most delightful developer experience possible. One way we do this is by making it as simple as possible to configure your DNS settings for custom domains. We provide a single IP address (our anycast IP address) to use in your DNS settings. When a request reaches one of the servers advertising that IP, we will forward it to one of possibly several origins around the world, depending on where your site is hosted and whether it's a web service or a static site.

We can't make any assumptions about where traffic will originate, and we can minimize latency by routing requests to the server closest to the end-user that's capable of responding to the request. For web services, the request always needs to go to the origin server--the server you've deployed to. But for static sites, we can rely on BGP to route requests to the server closest to the end-user; we advertise our IP from anycast servers worldwide, which inspect each request and forward it to a server capable of responding. So, the server that serves a request is one of hundreds of geographically distributed CDN edge servers containing a cached copy of your static site. If one of those servers fails, its peers will stop advertising the route and the traffic will be sent elsewhere.

Building an Anycast Network

Now that we understand the components that make up an anycast network, as well as the use cases for it, we're ready to dive into how you can build your own. At a high level, the steps for setting up anycast are:

Obtain an Autonomous System Number
Acquire an IP Address
Find a Hosting Provider
Configure BGP

Obtain an Autonomous System Number

The first step for setting up an anycast network is getting an autonomous system number (ASN). An ASN is a unique identifier that other ASs will use when announcing a path to reach you via BGP. Having an ASN is also a prerequisite for acquiring an IP address. ASNs are managed by five Regional Internet Registries. As the name suggests, each registry is responsible for managing the ASNs within specific geographic regions of the world.

Each registry has different requirements for acquiring an ASN. If you’re based in the United States, you'll work with ARIN to get yours. Their process is straightforward. You just need to submit a request with some supporting documentation along with an explanation of why you need the ASN. ARIN grants ASNs to organizations for two purposes:

Unique Routing Policy: Organizations who want to define routing policies that differ from their connected peers.
Multi-homed: Organizations that will be peering with multiple providers. Multi-homing is usually done to improve coverage and resiliency to failures of individual providers.

When Render applied for an ASN, we wanted the ability to advertise from multiple providers, so we used multi-homing as a justification for receiving an ASN. After submitting our application, ARIN responded with our ASN within a week.

Acquire an IP Address

Now that you have an ASN, you can acquire an IP block to advertise. The minimum IP prefix that can be advertised is a /24 for IPv4 and a /48 for IPv6. This limit exists to prevent the routing tables that ASs need to manage from growing too large.

You are going to need to decide whether you want to buy or lease your IP block. The dynamics at play here are similar to buying and leasing most things. Buying an IP block comes with a large upfront cost, while leasing requires less capital at the start but you will be paying a fee for as long as you use the IP block. Leasing also comes with additional terms and conditions on how you can use the IP block. If you have the capital and intend to use the IP block for an extended period of time, it likely makes sense to buy. Almost all available IPv4 addresses have been allocated and demand for them continues to rise. You can expect the cost to obtain them to continue to grow until IPv6 adoption is widespread enough to justify dropping support for IPv4.

Since we knew that we would need the IP block for the foreseeable future, we decided to buy one. Asking all of our users to update their DNS records would be extremely disruptive, so we wanted to ensure that our IP block would remain stable for as long as it was in use. We had a good experience using IPv4 Global to purchase our IP block. The remainder of this post will assume that you have chosen to buy instead of lease.

There are a couple of things you should verify before buying an IP block. The block needs to be registered with the Regional Internet Registry that you acquired your ASN from, or it must be transferable to them. You will also want to verify that the IP addresses in the block are in good standing. Some IP addresses have been used for nefarious purposes and end up on widely-used blocklists. There are many free services available that will check an IP address against the most popular databases of bad IPs.

Once you purchase your IP block, you will need to go through the process of transferring ownership from the previous holder of the IP block. The service you use to purchase the block will likely guide you through that process, which will involve working with your Regional Internet Registry to transfer ownership. The exact steps will depend on the registry and whether the block needs to be transferred between registries. You can look at ARIN's documentation to get an idea of what's involved in the process.

Find a Hosting Provider

Now that we have an IP address to advertise, it's time to determine what providers we will use to advertise it. Not all providers support BGP, so you're going to want to find ones that have the capability. In our anycast network setup process, we decided to go with Vultr and Equinix Metal.¹ The latter is a bare metal provider rather than a VPS provider, so you should verify whether that makes sense for your use case before deciding to go with them. We chose Vultr because they had global coverage, low cost, and thorough documentation on how to set up BGP. You can find discussions comparing VPS providers on forums like LowEndTalk to determine what provider makes sense for you.

Configure BGP

The next step is to set up your server and start accepting traffic for your anycast IP address. After getting your application running on the server, you can get started on configuring BGP.

When we configured BGP, we first needed to submit an application to Vultr requesting that they enable BGP for our account. They had us send a Letter of Authorization that allowed them to advertise our IP address from their platform. As a part of this process, Vultr created a record in the Internet Routing Registry on our behalf that signals to the rest of the internet how to handle traffic for our IP. It's a great UX to have Vultr take care of this for you. However, it’s important to note that Vultr will delete this record if you end up migrating away from them. You must create a new record before they delete their copy to avoid any service disruptions.

The next step is configuring BGP on your server. You're going to need to choose a BGP daemon to handle the advertisement. The two most common are Quagga and BIRD. We decided to use BIRD since Vultr recommended it and they have excellent documentation for getting it running.

After installing BIRD, create a file called /etc/bird.conf with the following contents:

router id 203.0.113.123 # IP of the Vultr server running BIRD

protocol bgp vultr
{
    local as 123456; # your ASN
    source address 203.0.113.123;
    import none;
    export all;
    multihop 2;
    neighbor 169.254.169.254 as 64515; # Vultr’s peering information
    password "my-secret-password"; # BGP password provided by Vultr
}

After restarting BIRD, your server will establish a peering session with Vultr’s AS. At this point, your server is capable of transmitting packets with the rest of the internet. Now you just need to tell the rest of the internet that you’re here! The final step is to announce your route. Append the following to the same bird.conf file:

protocol static
{
        route 123.4.567.890/24 via 203.0.113.123; # your IP via Vultr’s IP
}

protocol device
{
        scan time 5;
}

Restart BIRD again to load the new configuration. At this point, your BGP server is announcing the route to Vultr, who is in turn announcing the route to their peers (who then announce it to their peers). The process continues until your new route propagates across the internet. Your server can now serve traffic for your IP! Repeat these same steps with a second server in another region and you have your very own anycast network.

Conclusion

While this post provides the information needed to get your anycast network running, you may still need to adjust your settings to fine-tune the traffic patterns for your network. As mentioned previously, ASs usually choose the path with the fewest number of hops to a destination. Fewer hops does not necessarily mean it will be faster if, for example, one of those hops crosses the Atlantic Ocean. If you notice suboptimal performance, you may want to look into changing the traffic patterns with tools like communities and prepending.

Anycast networks are a powerful tool that leverages the networking infrastructure of the internet to create resilient and performant systems. I hope this post was insightful enough to add another tool to your toolbelt when building reliable systems.

We don't use Vultr or Equinix Metal anymore because of how our Anycast needs have evolved; we'll discuss our new setup in another blog post! ↩

Deploying Your Rails 6 App

Jake Malachowski — Fri, 24 Jul 2020 18:21:57 +0000

This article was originally published at: https://render.com/docs/deploy-rails. It's recommended to read the linked version with improved syntax highlighting.

This guide will demonstrate how you can set up a local Ruby on Rails 6 environment, create a simple view, and deploy it to Render. The application will be configured to use a Render PostgreSQL database.

The repository used for this demo can be found here and the sample app can be viewed here.

Create a Ruby on Rails Project

In this step, we will set up a local development environment with a basic project structure.

We will be calling this example project myrailssite. You can replace this with a name of your choosing.

Install Rails

To install Ruby on Rails on your machine, use the gem install command. Be sure you have the required dependencies installed (Ruby, Node.js and Yarn 1.x).
We are using Rails 6 in this tutorial, so verify that you have the correct version installed:

$ gem install rails
$ rails --version
Rails 6.0.3.2

Create a New Project

In your terminal, navigate to the directory where you will be creating your project. Then, run the following commands to generate a new project:
```
 $ rails new myrailssite --database=postgresql
```
You can make use of arguments to customize the generated project. Enter rails new -h for further details.

Create a local database for your application:

 $ rails db:create
 Created database 'myrailssite_development'
 Created database 'myrailssite_test'

This should create a fully functional basis for you new Rails application! To verify, you can start the development server:

$ rails server

To see your application in action, open a browser window and navigate to http://localhost:3000. You should see the Rails default information page:

Create the Hello World Landing Page

In this section, you will create a simple Rails application with a static view using Ruby on Rails. If you plan to deploy your sample Rails project on Render, skip to Update Your App For Render and deploy an empty project.

Checkout the official Getting Started with Rails guide for further reading on how to create Rails applications.

Create Your First Page

In order to create a new Rails controller, you need to run the controller generator. Set the controller's name to Render and set up an action named index using the following command:

 $ rails g controller Render index

The generator will create several files in your project:

 create  app/controllers/render_controller.rb
  route  get 'render/index'
 invoke  erb
 create    app/views/render
 create    app/views/render/index.html.erb
 invoke  test_unit
 create    test/controllers/render_controller_test.rb
 invoke  helper
 create    app/helpers/render_helper.rb
 invoke    test_unit
 invoke  assets
 invoke    scss
 create      app/assets/stylesheets/render.scss

2. Open the config/routes.rb file and add the following line:

Rails.application.routes.draw do
 get 'render/index'

 # For more details on this file's DSL, see https://guides.rubyonrails.org/routing.html
 root 'render#index'

This file will tell Rails that you want your render/index action to be accessible from the root URL of your application.

3. Open the app/views/render/index.html.erb file and replace its contents with:

<main class="container">
  <div class="row text-center justify-content-center">
    <div class="col">
      <h1 class="display-4">Hello World!</h1>
    </div>
  </div>
</main>

Add Third-Party CSS

In this step you will integrate Bootstrap into your application for easy styling.

In order to install Bootstrap, run the following command in your terminal:
```
 $ yarn add bootstrap
```
Rename your app/assets/stylesheets/application.css to app/assets/stylesheets/application.scss:
```
 $ mv app/assets/stylesheets/application.css app/assets/stylesheets/application.scss
```

Open app/assets/stylesheets/application.scss and replace its contents with:

 /*
  * This is a manifest file that'll be compiled into application.css, which will include all the files
  * listed below.
  *
  * Any CSS and SCSS file within this directory, lib/assets/stylesheets, or any plugin's
  * vendor/assets/stylesheets directory can be referenced here using a relative path.
  */

 @import "bootstrap/scss/bootstrap";

 @import "**/*";

So far, we imported Bootstrap into our CSS pack. This means Bootstrap will now be a part of the stylesheets served with our application.

Then, we replaced the existing require_* Rails directives with a plain SASS @import rule.

Both methods import all stylesheets from the app/assets/styleshets directory and its subdirectories. However, the use of the @import rule allows the imported stylesheets to access the SASS variables defined by Bootstrap.

4. Open app/views/layouts/application.html.erb and add the following modifications to the heading:

<!DOCTYPE html>
<html lang="<%= I18n.locale %>">
  <head>
   <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <title>Hello Rails on Render!</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>

    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>
  ...
</html>

Add an Image Asset

In order to add an asset to your project, download this banner and save it as app/assets/images/render.png:

2. In your layout, in app/views/layouts/application.html.erb, reference the downloaded image:

   ...
   <body>
      <header class="container mt-4 mb-4">
        <a href="https://render.com">
          <%= image_tag 'render.png', class: 'mw-100' %>
        </a>
      </header>
      <%= yield %>
   </body>
   </html>

You can now verify that your app is working using the following command:

$ rails server

Update Your App For Render

In order for your Rails project to be ready for production, you will need to make a few adjustments. If you haven't already, you will be required update your project to use a Render PostgreSQL database) instead of a SQLite database.

Modify Existing Rails Project for PostgreSQL

This is only required if the application was created without specifying --database=postgresql.

In your Gemfile change the requirement for the existing database driver:

from:
```
 gem 'sqlite3'
```
to:
```
 gem 'pg'
```
Install your new dependencies using the following command. This will also update your Gemfile.lock:
```
 $ bundle install
```

Open config/database.yml and update it to use the postgresql database adapter.:

 # PostgreSQL. Versions 9.3 and up are supported.
 #
 # Install the pg driver:
 #   gem install pg
 # On macOS with Homebrew:
 #   gem install pg -- --with-pg-config=/usr/local/bin/pg_config
 # On macOS with MacPorts:
 #   gem install pg -- --with-pg-config=/opt/local/lib/postgresql84/bin/pg_config
 # On Windows:
 #   gem install pg
 #       Choose the win32 build.
 #       Install PostgreSQL and put its /bin directory on your path.
 #
 # Configure Using Gemfile
 # gem 'pg'
 #
 default: &default
   adapter: postgresql
   encoding: unicode
   # For details on connection pooling, see Rails configuration guide
   # https://guides.rubyonrails.org/configuring.html#database-pooling
   pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

 development:
   <<: *default
   database: myrailssite_development

   # The specified database role being used to connect to postgres.
   # To create additional roles in postgres see `$ createuser --help`.
   # When left blank, postgres will use the default role. This is
   # the same name as the operating system user that initialized the database.
   #username: myrailssite

   # The password associated with the postgres role (username).
   #password:

   # Connect on a TCP socket. Omitted by default since the client uses a
   # domain socket that doesn't need configuration. Windows does not have
   # domain sockets, so uncomment these lines.
   #host: localhost

   # The TCP port the server listens on. Defaults to 5432.
   # If your server runs on a different port number, change accordingly.
   #port: 5432

   # Schema search path. The server defaults to $user,public
   #schema_search_path: myapp,sharedapp,public

   # Minimum log levels, in increasing order:
   #   debug5, debug4, debug3, debug2, debug1,
   #   log, notice, warning, error, fatal, and panic
   # Defaults to warning.
   #min_messages: notice

 # Warning: The database defined as "test" will be erased and
 # re-generated from your development database when you run "rake".
 # Do not set this db to the same as development or production.
 test:
   <<: *default
   database: myrailssite_test

 # As with config/credentials.yml, you never want to store sensitive information,
 # like your database password, in your source code. If your source code is
 # ever seen by anyone, they now have access to your database.
 #
 # Instead, provide the password as a unix environment variable when you boot
 # the app. Read https://guides.rubyonrails.org/configuring.html#configuring-a-database
 # for a full rundown on how to provide these environment variables in a
 # production deployment.
 #
 # On Heroku and other platform providers, you may have a full connection URL
 # available as an environment variable. For example:
 #
 #   DATABASE_URL="postgres://myuser:mypass@localhost/somedatabase"
 #
 # You can use this database configuration with:
 #
 #   production:
 #     url: <%= ENV['DATABASE_URL'] %>
 #
 production:
   <<: *default
   database: myrailssite_production
   username: myrailssite
   password: <%= ENV['MYRAILSSITE_DATABASE_PASSWORD'] %>

Go Production-Ready

Before deploying any serious application in production, some minor tweaks are required.

Open config/database.yml and find the production section. Modify it to gather the database configuration from the DATABASE_URL environment variable:

   production:
      <<: *default
      url: <%= ENV['DATABASE_URL'] %>

2. Open config/puma.rb and uncomment and add the highlighted lines:

 # Puma can serve each request in a thread from an internal thread pool.
 # The `threads` method setting takes two numbers: a minimum and maximum.
 # Any libraries that use thread pools should be configured to match
 # the maximum value specified for Puma. Default is set to 5 threads for minimum
 # and maximum; this matches the default thread size of Active Record.
 #
 max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
 min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
 threads min_threads_count, max_threads_count

 # Specifies the `port` that Puma will listen on to receive requests; default is 3000.
 #
 port        ENV.fetch("PORT") { 3000 }

 # Specifies the `environment` that Puma will run in.
 #
 environment ENV.fetch("RAILS_ENV") { "development" }

 # Specifies the `pidfile` that Puma will use.
 pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

 # Specifies the number of `workers` to boot in clustered mode.
 # Workers are forked web server processes. If using threads and workers together
 # the concurrency of the application would be max `threads` * `workers`.
 # Workers do not work on JRuby or Windows (both of which do not support
 # processes).
 #
 workers ENV.fetch("WEB_CONCURRENCY") { 4 }

 # Use the `preload_app!` method when specifying a `workers` number.
 # This directive tells Puma to first boot the application and load code
 # before forking the application. This takes advantage of Copy On Write
 # process behavior so workers use less memory.
 #
 preload_app!

 # Allow puma to be restarted by `rails restart` command.
 plugin :tmp_restart

3. Open config/environments/production.rb and enable the public file server when the RENDER environment variable is present (which always is on Render):

 # Disable serving static files from the `/public` folder by default since
 # Apache or NGINX already handles this.
 config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present? || ENV['RENDER'].present?

Create a Build Script

You will need to run a series of commands to build your app. This can be done using a build script. Create a script called bin/render-build.sh at the root of your repository:

#!/usr/bin/env bash
# exit on error
set -o errexit

bundle install
bundle exec rake assets:precompile
bundle exec rake assets:clean
bundle exec rake db:migrate

Make sure the script is executable before checking it into Git:

$ chmod a+x bin/render-build.sh

We will configure Render to call this script on every push to the Git repository.

Commit all changes and push them to your GitHub repository. Now your application is ready to be deployed on Render!

Deploy to Render

There are two ways to deploy your application on Render, either by declaring your services within your repository in a render.yaml file, or by manually setting up your services using the dashboard. In the following steps, we will walk you through both options.

Use `render.yaml` to Deploy

Create a file named render.yaml at the root of your directory with the following content. The file will include information about your Rails Web Service and the Database that is used by your application. Don't forget to commit and push it to your remote repository.

   databases:
      - name: myrailssite
        databaseName: myrailssite
        user: myrailssite

   services:
      - type: web
        name: myrailssite
        env: ruby
        buildCommand: "./bin/render-build.sh"
        startCommand: "bundle exec puma -C config/puma.rb"
        envVars:
          - key: DATABASE_URL
            fromDatabase:
              name: myrailssite
              property: connectionString
          - key: RAILS_MASTER_KEY
            sync: false

2. On the Render Dashboard, go to the YAML page and click the New From YAML button. Select your repository (after giving Render the permission to access it, if you haven't already).

3. In the deploy window, set the value of the RAILS_MASTER_KEY to the contents of your config/master.key file. Then click Approve.

That's it! Your app will be live on your .onrender.com URL as soon as the build finishes.

Deploy Manually

If you don't wish to deploy your Rails app through YAML deploys, you can follow these steps for a manual deploy.

Create a new PostgreSQL database on Render. Note your database internal connection string; you will need it later.
Create a new Web Service, pointing it to your application repository (make sure Render has a permission to access it).
Select Ruby for the environment and set the following properties:

Property	Value
Build Command	`./bin/render-build.sh`
Start Command	`bundle exec puma -C config/puma.rb`

4. Add the following environment variables under the Advanced section:

Key	Value
`DATABASE_URL`	The internal connection string for the database you created above
`RAILS_MASTER_KEY`	Paste contents of the `config/master.key` file

That's it! You can now finalize your service deployment. It will be live on your .onrender.com URL as soon as the build finishes.

Additional Notes

By default, Render uses the latest LTS version of Ruby. You can also modify the version of Ruby used by specifying it in .ruby-version at the root of your project, or in your Gemfile like this:

ruby '2.7.1'

Deploying your Django 3 App

Jake Malachowski — Mon, 20 Jul 2020 18:48:41 +0000

This article was originally published at: https://render.com/docs/deploy-django. It's recommended to read the linked version with improved syntax highlighting.

This guide will demonstrate how you can set up a local Django development environment, create a simple view, and deploy it to Render. The application will be configured to use a Render PostgreSQL database and will use Poetry to manage the Python virtual environment and project dependencies, though neither are requirements to deploy a Django project on Render.

The finished code for this example is available on Github and the sample app can be viewed here.

This tutorial starts with a bare-bones installation and explains all required code modifications, so it should be straightforward to adapt it to any custom configuration in your existing Django codebase.

Create a Django Project

In this step, we will set up a local development environment and create basic project structure.

We will assume our project is called mysite and consistently use it throughout the code. Feel free to choose a different name, though it must be a valid Python package name.

Install Poetry

If you do not have Poetry installed, follow the Poetry installation instructions for your operating system. In most cases, you will simply need to run the following:

macOS/Linux:

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python

Windows in PowerShell:

(Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python

You may need to restart your shell to load the poetry command into your PATH. To verify the installation was successful, try running poetry --version.

Create Project Structure

Use Poetry to initialize your project directory:

   $ poetry new mysite
   Created package mysite in mysite
   $ cd mysite
   $ ls
   README.rst     mysite         pyproject.toml tests

   # We don't need the code for our package that was generated by Poetry, so:
   $ rm -rf mysite tests

In pyproject.toml, ensure the Python version requirement includes version 3.7, which is available on Render.

   [tool.poetry.dependencies]
   python = "^3.7"

Add Django as a dependency.

    $ poetry add django

Create a Django project for your application.

   $ poetry run django-admin startproject mysite .

You should end up with the following directory structure:

   $ tree
   .
   ├── README.rst
   ├── manage.py
   ├── mysite
   │   ├── __init__.py
   │   ├── asgi.py
   │   ├── settings.py
   │   ├── urls.py
   │   └── wsgi.py
   ├── poetry.lock
   └── pyproject.toml

   1 directory, 9 files

At this point, you should have a fully-functional scaffolding for your new Django application! To verify, you can start the development server.

$ poetry run ./manage.py runserver

Create the Hello World Landing Page

In this section, you will create a simple Django application with a static view, template, and an example static file that showcases the basic steps in creating a page using Django. If you are only interested in learning how to deploy a sample Django project to Render, you can skip to the Update Your App For Render section and deploy an empty project.

If you wish to build something more complex, it's highly recommended to read the official Writing your first Django app guide.

Create the Render app

Now that your application environment (a Django project) is ready, you are ready to start working on the application itself.

Django projects are collections of applications, wired together to form a website. Django provides a number of built-in applications, with the admin site being a well-known example.

To create your application, run the following command from the root directory of your project:

   python manage.py startapp render

This will create a directory named render with following contents:

   $ tree render
   render
   ├── __init__.py
   ├── admin.py
   ├── apps.py
   ├── migrations
   │   ├── __init__.py
   ├── models.py
   ├── tests.py
   └── views.py

   1 directory, 7 files

You also need to inform Django about your new application. Open mysite/settings.py, find definition of the INSTALLED_APPS setting, and add a reference to the RenderConfig class at the beginning of the list:

   # https://docs.djangoproject.com/en/3.0/ref/settings/#installed-apps
   INSTALLED_APPS = [
       'render.apps.RenderConfig',
       'django.contrib.admin',
       'django.contrib.auth',
       ...
   ]

Write Your First View

In render/views.py add the following Python code:

   from django.shortcuts import render

   def index(request):
       return render(request, 'render/index.html', {})

This is one of the simplest views possible in Django. It renders the render/index.html template, which we will create in a later step.

Create the render/urls.py file and add following code:

   from django.urls import path

   from . import views

   urlpatterns = [
       path('', views.index, name='index'),
   ]

This file will tell Django that you want your index view be accessible from the root URL of your application.

Configure the root project urlpatterns to point to the urls module of the render application. Open mysite/urls.py, add an import for django.urls.include, and include your application's URLs:

   from django.contrib import admin
   from django.urls import path, include

   urlpatterns = [
       path('admin/', admin.site.urls),
       path('', include('render.urls')),
   ]

Create the render/index.html template you referenced earlier. Create a new file render/templates/render/index.html and add the following HTML:

   <!doctype html>
   <html lang="en">
   <head>
       <meta charset="UTF-8">
       <meta http-equiv="X-UA-Compatible" content="IE=edge" />
       <meta name="viewport" content="width=device-width, initial-scale=1.0" />

       <title>Hello Django on Render!</title>

       <link rel="stylesheet"
             href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.0/css/bootstrap.min.css"
             integrity="sha384-9aIt2nRpC12Uk9gS9baDl411NQApFmC26EwAOH8WgZl5MYYxFfc+NcPb1dKGj7Sk"
             crossorigin="anonymous">
   </head>
   <body>
   <main class="container">
       <div class="row text-center justify-content-center">
           <div class="col">
               <h1 class="display-4">Hello World!</h1>
           </div>
       </div>
   </main>
   </body>
   </html>

Add a static file to your application. Download this image and save it as render/static/render/render.png:

In your template, load the static module and reference the downloaded image:

   {% load static %}

   <!doctype html>
   <html lang="en">
   ...
   <body>
   <header class="container mt-4 mb-4">
       <a href="https://render.com">
           <img src="{% static "render/render.png" %}" alt="Render" class="mw-100">
       </a>
   </header>
   ...
   </body>
   </html>

You can now verify your app is working with the following command:

   $ python manage.py runserver

Update Your App For Render

In order for your Django project to be ready for production, you will need to make a few adjustments in the application settings. You will update your project to use a Render PostgreSQL database instead of a SQLite database and configure WhiteNoise to serve your static files.

Go Production-Ready

Before deploying any serious application onto production environment, you need to ensure it's properly secured and configured. Django documentation provides a useful deployment checklist, which we will follow in this step.

Open mysite/settings.py and find the declaration of the SECRET_KEY setting. We do not want to store production secrets in source code, so we'll fetch it from an environment variable that we'll create later:

   # SECURITY WARNING: keep the secret key used in production secret!
   SECRET_KEY = os.environ.get('SECRET_KEY', default='your secret key')

Find the declaration of the DEBUG setting. This setting should never be set to True in a production environment. You can detect if you are running on Render by checking if the RENDER environment variable is present in the application environment.

   # SECURITY WARNING: don't run with debug turned on in production!
   DEBUG = 'RENDER' not in os.environ

When DEBUG = False, Django will not work without a suitable value for ALLOWED_HOSTS. You can get the name of your web service host from the RENDER_EXTERNAL_HOSTNAME environment variable, which is automatically set by Render.

   # https://docs.djangoproject.com/en/3.0/ref/settings/#allowed-hosts
   ALLOWED_HOSTS = []

   RENDER_EXTERNAL_HOSTNAME = os.environ.get('RENDER_EXTERNAL_HOSTNAME')
   if RENDER_EXTERNAL_HOSTNAME:
       ALLOWED_HOSTS.append(RENDER_EXTERNAL_HOSTNAME)

If you add a custom domain to your Render app, don't forget to add your new domain to the list.

Configure Django for PostgreSQL

For convenience, we will add the DJ-Database-URL package, which allows us to specify databases in Django using connection strings. Render Databases automatically provide connection strings in their control panel, which we will then provide to our web service via the DATABASE_URL environment variable. We will also need to add psycopg2 to the project.

Run following command to add necessary dependencies to your project:

   $ poetry add dj-database-url psycopg2-binary

In mysite/settings.py, find declaration of the DATABASES setting and modify it to look as follows:

   # Don't forget to import dj-database-url at the beginning of the file
   import dj_database_url

   # Database
   # https://docs.djangoproject.com/en/3.0/ref/settings/#databases

   DATABASES = {
       'default': dj_database_url.config(
           # Feel free to alter this value to suit your needs.
           default='postgresql://postgres:postgres@localhost:5432/mysite',
           conn_max_age=600
       )
   }

Static Files

Websites generally need to serve additional files such as images, JavaScript, and CSS. In Django, these files are referred to as static files and it provides a dedicated module for collecting them into single place for serving in production.

The built-in module only supports moving files from one place to another, relying on web servers such as Apache or NGINX to serve them to end users. On Render, the internet-facing web server is provided by default and we need a way to host static files using it. In this step, we will set up WhiteNoise which is a highly popular solution for this problem. The following instructions are a short brief of the procedure described in the WhiteNoise documentation.

Add WhiteNoise as a dependency (adding Brotli support is optional, but recommended):

   poetry add 'whitenoise[brotli]'

Open mysite/settings.py, find the MIDDLEWARE list, and add the WhiteNoise middleware just after SecurityMiddleware:

   MIDDLEWARE = [
       'django.middleware.security.SecurityMiddleware',
       'whitenoise.middleware.WhiteNoiseMiddleware',
       ...
   ]

Find the section where static files are configured. Apply following modifications:

   # Static files (CSS, JavaScript, Images)
   # https://docs.djangoproject.com/en/3.0/howto/static-files/

   # This setting tells Django at which URL static files are going to be served to the user.
   # Here, they well be accessible at your-domain.onrender.com/static/...
   STATIC_URL = '/static/'

   # Following settings only make sense on production and may break development environments.
   if not DEBUG:
       # Tell Django to copy statics to the `staticfiles` directory
       # in your application directory on Render.
       STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

       # Turn on WhiteNoise storage backend that takes care of compressing static files
       # and creating unique names for each version so they can safely be cached forever.
       STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

Create a Build Script

We need to run a series of commands to build our app. We can accomplish this with a build script. Create a script called build.sh at the root of your repository:

   #!/usr/bin/env bash
   # exit on error
   set -o errexit

   poetry install

   python manage.py collectstatic --no-input
   python manage.py migrate

Make sure the script is executable before checking it into Git:

   $ chmod a+x build.sh

We will configure Render to call this script on every push to the Git repository.

We are going to run our application with Gunicorn. Add the dependency to your project:

   poetry add gunicorn

Commit all changes and push them to your GitHub repository. Now your application is ready to be deployed on Render!

Deploy to Render

There are two ways to deploy your application on Render, either by declaring your services within your repository using a render.yaml file or by manually setting up your services using the dashboard. In this tutorial, we will walk through both options.

Use `render.yaml` for Deployments

Create a file named render.yaml in the root of your directory. The file will define your Django Web Service and the Database used by your application. Don't forget to commit and push it to your remote repository.

   databases:
     - name: mysite
       databaseName: mysite
       user: mysite

   services:
     - type: web
       name: mysite
       env: python
       buildCommand: "./build.sh"
       startCommand: "gunicorn mysite.wsgi:application"
       envVars:
         - key: DATABASE_URL
           fromDatabase:
             name: mysite
             property: connectionString
         - key: SECRET_KEY
           generateValue: true
         - key: WEB_CONCURRENCY
           value: 4

On the Render Dashboard, go to the YAML page and click New From YAML button. Select your application repository (give Render permission to access it if you haven't already) and click Approve on the next screen.

That's it! Your app will be live on your .onrender.com URL as soon as the build finishes.

If you skipped the Create the Hello World Landing Page section, you will see a Not Found error when visiting your site. You can verify your deploy was successful by visiting the admin dashboard at /admin

Manual Deployment

Create a new PostgreSQL database on Render. Note your database internal connection string; you will need it later.
Create a new Web Service, pointing it to your application repository (give Render permission to access it if you haven’t already).
Select Python for the environment and set following properties:

Property	Value
Build Command	`./build.sh`
Start Command	`gunicorn mysite.wsgi:application`

Add the following environment variables under Advanced:

Key	Value
`DATABASE_URL`	The internal connection string for the database you created above
`SECRET_KEY`	Click `Generate` to get a secure random value
`WEB_CONCURRENCY`	`4`

That's it! Save your web service to deploy your Django application on Render. It will be live on your .onrender.com URL as soon as the build finishes.

Create Django Admin Account

Once your application is live, create a new Django admin account by running the following command in the Render Shell:

$ ./manage.py createsuperuser

Forem: Jake Malachowski

How to Build an Anycast Network

A Brief Overview of the Internet

What is Anycast?

How Render Uses Anycast

Building an Anycast Network

Obtain an Autonomous System Number

Acquire an IP Address

Find a Hosting Provider

Configure BGP

Conclusion

Deploying Your Rails 6 App

Create a Ruby on Rails Project

Install Rails

Create a New Project

Create the Hello World Landing Page

Create Your First Page

Add Third-Party CSS

Add an Image Asset

Update Your App For Render

Modify Existing Rails Project for PostgreSQL

Go Production-Ready

Create a Build Script

Deploy to Render

Use render.yaml to Deploy

Deploy Manually

Additional Notes

Deploying your Django 3 App

Create a Django Project

Install Poetry

Create Project Structure

Create the Hello World Landing Page

Create the Render app

Write Your First View

Update Your App For Render

Go Production-Ready

Configure Django for PostgreSQL

Static Files

Create a Build Script

Deploy to Render

Use render.yaml for Deployments

Manual Deployment

Create Django Admin Account

Use `render.yaml` to Deploy

Use `render.yaml` for Deployments