Deploying a Web App, an API, and a Website under the same domain
In this post we look at how Altostra makes it simple to deploy multiple web facing components under the same domain.
October 6 2020 · 5 min read
Managing websites and application that are accessible via our domain can be tedious - it requires managing multiple records and understanding what each record points to.
In this post, we explore how Altostra can can simplify the process.
What you will need
An Amazon Certificate Manager (ACM) certificate that identifies you as the owner of your domain.
You can either request a certificate directly from ACM, or import an already existing certificate into it. For more information, read the AWS docs.
Route53 Hosted Zone
An AWS Route53 hosted-zone that corresponds with your domain. Altostra creates the DNS records for you, but you do need to have a pre-existing Route53 DNS Zone to host them.
A hosted zone contains records that define how internet traffic is routed for your domain and its subdomains.
For example, in the
example.comhosted zone, you can create records for
www.example.comthat route traffic to a web server, CDN or a REST API endpoint.
For more information about how to configure a hosted-zone for your domain read the AWS docs.
Building our domain
We create a project and populate it with the following:
- A static website
- A web application that has:
- Statically served client application
- REST API that serves the logic of the application
- A domain to host the web-site and application
The static website comes included and configured in an Altostra template - so we can use it jump start our project.
We begin by creating a new project from the
alto templates command, we can see which templates are available to us,
then using the
alto init --template static-website we initialize a new project
from that template:
$ mkdir static-website $ cd static-website $ alto templates ✔ Getting project templates Available templates: * static-website * ... $ alto init --template static-website ✔ Getting template 'static-website' ✔ Initializing project $ npm init -y; echo node_modules > .gitignore $ git init $ git add -A . $ git commit -m "Initial commit"
Since we are starting from the static website template, we have to add a domain, another CDN and another bucket, and an API with a few endpoints.
We configure the domain to use a parameter named
DOMAIN as the domain name.
We also add functions to be called by the API endpoints, and a table to retain some application data.
We need to configure our domain to meet our requirements.
Starting with the Domain resource, we configure it to use parameters from the
environment it's deployed too.
We enable the Register in DNS checkbox and save. Without this, the DNS records are not created and only the configuration for the other resources is applied.
The connection to the static website CDN is already using a
CERT_ARN, so we only need to set the host name to
to make it accessible via
Similarly, we will set the host name for the application files CDN to
app and the
API's name to
Setting the environment
Our project is parameterized so that we are able to deploy it to different environments where each environment provides its own configuration values for the project parameters.
We can set the parameters explicitly for every deployment using configuration-set file, but this is error-prone and can lead to misconfiguration of deployments.
Instead, we will set the configuration in the environment, thus sharing the configuration with other deployments in the same environment, and allowing us to seamlessly deploy the same image to different environments, each having appropriate configuration.
Using Altostra Web-Console, we edit our environment configuration to include
DOMAIN_CERT parameters with appropriate values.
Web site content and functions code
For brevity, we skip the process of adding the web content of the website and the web app, and also the source code for the functions. We touched on the subject of static websites in previous posts, you can find these on our blog.
In order to deploy an Altostra project, we need to create an image.
We can then deploy that image to an environment of our choice.
We create an image named
$ alto push v1.0 ✔ Validating tag name 'v1.0' ✔ Checking user credentials ✔ Loading project ✔ Validating project file integrity ✔ Loading project ✔ Getting build repository ✔ Updating project file ✔ Validating image availability ✔ Packing files ✔ Getting repository information ✔ Uploading project parts
Now, because we don't have an existing deployment of our project, we need to create one.
Assuming an environment named
Demo already exists, we create a new deployment
main from our image by running the following command:
$ alto deploy main:v1.0 --new Demo ✔ Processing request ✔ Deploying project Deployment status of deployment main: ┌─────────┬───────────────────┬─────────────────────────┬────────┬─────────────┐ │ (index) │ User │ Date │ Image │ Status │ ├─────────┼───────────────────┼─────────────────────────┼────────┼─────────────┤ │ 0 │ 'Shlomi Borovitz' │ '10/4/2020, 1:14:23 PM' │ 'v1.0' │ 'Deploying' │ └─────────┴───────────────────┴─────────────────────────┴────────┴─────────────┘
Finally, we upload our site content by running:
$ alto sync main --all --public ✔ Checking user credentials ✔ Loading project ✔ Validating buckets ✔ Getting repository information ✔ Syncing files to site-files
And invalidate all CDN caches by running:
$ alto invalidate main --all ✔ Checking user credentials ✔ Loading project ✔ Getting build repository ✔ Validating project ✔ Validating CDNs ✔ Invalidating CDN caches ✔ Invalidation process is in progress. This may take a while.
In this post we saw how Altostra can help you manage multiple websites and applications under a single domain, automating the creation of all the underlying cloud resources such as custom domains, DNS records and policies.
You can also deploy with different domain names per environment by providing the domain names and certificates as environment configuration to be applied during deployment.