Skip to content
Snippets Groups Projects
Unverified Commit d2fabad9 authored by Jeff Bruemmer's avatar Jeff Bruemmer Committed by GitHub
Browse files

docs - deprecate beanstalk (#33067)

* alternatives

* remove links

* remove mentions of eb

* remove eb from rds page
parent 5695df91
Branches
Tags
No related merge requests found
Showing
with 63 additions and 378 deletions
......@@ -38,4 +38,4 @@ If you have an SSL certificate and would prefer to have Metabase run over HTTPS
Be sure to replace `path/to/keystore.jks` and `storepass` with the correct path to and password for your [Java KeyStore](https://www.digitalocean.com/community/tutorials/java-keytool-essentials-working-with-java-keystores). With the above settings applied you will be running Metabase on port 8443 over HTTPS using the supplied certificate.
No idea how to generate a Java KeyStore yourself? This is sort of an advanced topic, but if you're feeling froggy you can read more about how to configure SSL in Jetty [in their own documentation](https://www.eclipse.org/jetty/documentation/jetty-9/index.html#configuring-ssl). Otherwise, you'll probably find it easiest to handle SSL termination outside of Metabase, for example by the Elastic Load Balancer if deploying via Elastic Beanstalk.
\ No newline at end of file
No idea how to generate a Java KeyStore yourself? This is sort of an advanced topic, but if you're feeling froggy you can read more about how to configure SSL in Jetty [in their own documentation](https://www.eclipse.org/jetty/documentation/jetty-9/index.html#configuring-ssl). Otherwise, you'll probably find it easiest to handle SSL termination outside of Metabase.
\ No newline at end of file
---
title: Advanced topics for running Metabase on Elastic Beanstalk
redirect_from:
- /docs/latest/operations-guide/advanced-topics-for-running-Metabase-in-AWS-ElasticBeanstalk
---
# Advanced topics for running Metabase on Elastic Beanstalk
## Logging
### Network Access log
If you need a log of all the IP addresses and URLs that were accessed during a specific period, you can configure the Load Balancer to send those logs to S3. This is useful for analyzing the traffic to your Metabase instance.
To enable this logging, you have to go to the settings of the Load Balancer and enable **Store Logs** in the **Access Log Files** section. You will need to choose an S3 bucket to dump the logs in, and a prefix that will identify the logs coming from this load balancer.
### Application Logs
If you want to retain the Metabase application logs, you can publish them to an S3 bucket:
- On your Metabase Elastic Beanstalk environment, click on the `Configuration` link in the navigation bar on the left side. On the configuration page, click on the `Edit` button next to `Software`.
- Scroll down and then check the box next to **Enabled** in S3 log storage section.
- Click `Save` in the bottom right corner.
You'll need to wait a minute for the logging to kick in, but then you should be good to go. Elastic Beanstalk will now periodically publish the application log files to S3, which you can download whenever you need to analyze them.
### Using Papertrail for logging on AWS
You can also use the [Papertrail logging service](https://www.papertrail.com/) for collecting your application logs.
- Click on **Configuration** on the left hand sidebar.
- Under the _Web Tier_ section, scroll down to **Software Configuration** and click the gear icon.
- Under **Environment Properties** add the following entries:
- `PAPERTRAIL_HOST` - provided by Papertrail
- `PAPERTRAIL_PORT` - provided by Papertrail
- `PAPERTRAIL_HOSTNAME` - the name you want to see showing up in Papertrail for this server
- Scroll to the bottom of the page and click **Apply** in the lower right, then wait for your application to update.
_NOTE: Sometimes these settings will not apply until you restart your application server, which you can do by either choosing `Restart App Server(s)` from the Actions dropdown or by deploying the same version again._
## Running Metabase over HTTPS
There is no requirement to run Metabase over HTTPS, but we are sticklers for security and believe you should always be careful with your data. Here's how to set up HTTPS on AWS.
### Upload a Server Certificate
First, you need to open a new tab in your browser and search for AWS certificate manager in your AWS Dashboard. Once inside, you have the options for provisioning certificates or become a private certificate authority. We will choose `Provision certificates` and we will click on `Get Started`.
A blue button will appear on the top of the page with the feature to import certificates (you can also ask AWS for a new certificate if needed and they will provision one for you)
Follow the steps to input your certificates details. Once you submit your certificate details, you'll see the certificate in other tools of AWS (like HTTPS on your load balancer).
### Setup DNS CNAME (using AWS)
- Open up AWS **Route 53** by navigating to **Services > Networking > Route 53** in the AWS Console header.
- Click on **Hosted Zones**, then click on the domain name you want to use for Metabase.
- Click on the blue button **Create Record** (a new panel will open up).
- Enter in a **Record name**: for your application. This record name should be the exact URL you plan to access Metabase with (e.g. `metabase.mycompany.com`).
- Under the dropdown for **Record type**: select _A – Routes traffic to an IPv4 address and some AWS resources_.
- Enable the **Alias** switch. For the **Route traffic to** option, select **Alias to Application and Classic Load Balancer**, region **US East (Ohio) [us-east-2]**, or the one that you deployed your instance to (e.g. `mycompany-metabase.elasticbeanstalk.com`).
- Choose the load balancer that corresponds to your instance.
- Leave all other settings in their default values.
- At the bottom of the page, click **Create Record** .
After creating the record, the record can take ten minutes (sometimes longer) to propagate on the Internet.
### Modify Metabase to enforce HTTPS
Before trying to enable HTTPS support, you must upload a server certificate to your AWS account.
- Go to Elastic Beanstalk and select your **Metabase** application.
- Click on Environment that you would like to update.
- One the left sidebar, click **Configuration**.
- Scroll down to **Load Balancer** and click the Edit button on the right of the screen.
- On Listeners section, click on **Add Listener** and change the Protocol to HTTPS on the modal window that opens.
- Set the value for **Port** to 443.
- Click on **SSL certificate ID** and choose the name of the certificate that you uploaded.
- The certificate MUST match the domain you plan to use for your Metabase install.
- In SSL Policy select "ELBSecurityPolicy-TLS-1-2-2017-01".
- Scroll to the bottom of the page and click **Save**.
Your Environment will begin updating with your new change. You will have to wait for this to complete before making additional updates.
Once this change is made you will no longer be able to access your Metabase instance at the \*.elasticbeanstalk.com URL provided by Amazon because it will result in a certificate mismatch. To continue accessing your secure Metabase instance you must [Set up a DNS CNAME](#setup-dns-cname-using-aws).
Once your application is working properly over HTTPS, we recommend setting an additional property to force non-HTTPS clients to use the HTTPS endpoint.
- Click on **Configuration** on the left hand sidebar.
- Scroll down to **Software Configuration** under the _Web Tier_ section and click the gear icon to edit those settings.
- Under **Environment Properties** add an entry for `NGINX_FORCE_SSL` with a value of `1`.
- Scroll to the bottom of the page and click **Apply** in the lower right, then wait for your application to update.
- Click on `Configuration` on the left hand sidebar.
- One the left sidebar, click **Configuration**.
- Scroll down to `Load Balancer` and click the Edit button on the right of the screen.
- On Listeners section, click on "Add Listener" and change the Protocol to HTTPS on the modal window that opens.
- Set the value for `Port` to _443_.
- Then, a little bit lower on the dropdown for `SSL certificate ID`, choose the name of the certificate that you uploaded to your account.
- _NOTE: The certificate MUST match the domain you plan to use for your Metabase install._
- In SSL Policy select `ELBSecurityPolicy-TLS-1-2-2017-01`
- Scroll to the bottom of the page and click `Save` in the lower right.
- _NOTE: Your Environment will begin updating with your new change. You will have to wait for this to complete before making additional updates._
- _IMPORTANT: Once this change is made you will no longer be able to access your Metabase instance at the `*.elasticbeanstalk.com` URL provided by Amazon because it will result in a certificate mismatch. To continue accessing your secure Metabase instance you must [Setup a DNS CNAME](#setup-dns-cname-using-aws)._
Once your application is working properly over HTTPS, we recommend setting an additional property to force non-HTTPS clients to use the HTTPS endpoint.
- Click on `Configuration` on the left hand sidebar.
- Scroll down to `Software Configuration` under the _Web Tier_ section and click the gear icon to edit those settings.
- Under `Environment Properties` add an entry for `NGINX_FORCE_SSL` with a value of `1`.
- Scroll to the bottom of the page and click `Apply` in the lower right, then wait for your application to update.
## RAM usage monitoring
Metabase installs the CloudWatch agent into the Elastic Beanstalk deployment, which sends data about your deployment to CloudWatch, allowing you to track your Metabase's RAM usage and other metrics.
To set up CloudWatch for your Elastic Beanstalk environment, follow the steps in the AWS documentation to [grant permissions to publish CloudWatch metrics](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-cw.html#customize-containers-cw-policy).
## Automated security assessment
Metabase installs the AWS Inspector into the Elastic Beanstalk deployment, so you can have real-time assessments about your instance's security that you can integrate into other AWS products. To start the automated checks on your instance, you only need to enable the Inspector in AWS's console.
## About NGINX configs inside Elastic Beanstalk deployments
In the near future we will be removing the custom NGINX configuration that was being bundled with Metabase in the previous configurations, so in the case that you were using configurations like NGINX_FORCE_SSL or custom certificates, you will need to move these configurations to AWS Application Load Balancers. To do this, check out the [enabling VPC](./running-metabase-on-elastic-beanstalk.md#22-enabling-vpc) part of the Elastic Beanstalk guide where it's specified how to use an Application Load Balancer with your Elastic Beanstalk configuration, or otherwise start over the creation of your Elastic Beanstalk deployment [having made a backup first](backing-up-metabase-application-data.md) of your application database so you don't lose your Metabase configuration.
......@@ -6,52 +6,57 @@ redirect_from:
# Creating an RDS database on AWS
## Configuring RDS for Metabase
If you want to move from using Metabase just for testing to something that is ready for the big time, you need to use either PostgreSQL or MySQL/MariaDB for you application database. Here's a high-level view of Metabase deployed with a dedicated application database.
If you want to move from using Metabase just for testing to something that is ready for the big time, you need to use a production-grade database like PostgreSQL or MySQL/MariaDB. Here's a [high level architecture diagram](images/Metabase-AWS-SI.png) of Metabase deployed with a dedicated application database.
![high level architecture diagram](images/Metabase-AWS-SI.png)
## Step 1
## Create a database
In AWS, enter RDS in the search box or select RDS from the dropdown button on the top left of the page. Once inside RDS, click on the **Create database** button.
## Step 2
Select PostgreSQL or MySQL as the engine type. For this example we will choose PostgreSQL on its latest version available in AWS at the time of writing (12.4-R1).
- Create Database: select MySQL or PostgreSQL as engine types, as these two are the ones that Metabase support as the Application Database (where Metabase will save all of its configurations). For this example we will choose PostgreSQL on its latest version available in AWS at the time of writing (12.4-R1).
Templates: you can leave "Production" selected, or choose any other option that better suits your needs.
- Templates: you can leave "Production" selected, or choose any other option that better suits your needs.
Settings: type a unique **DB instance identifier** for your database. You'll need the username and master password to configure the environment variables in Metabase.
- Settings: type a unique **DB instance identifier** for your database. You'll need the username and master password to configure the environment variables in Metabase.
![RDS Templates Section](images/RDSPostgresSettings.png)
- Instance size: the sizing of the RDS instance depends on the number of Metabase instances that will be connected to this database, the number of simultaneous users who are using Metabase, and the number of questions, dashboards, and configurations that are saved. To start, a `t3.small` is a good choice.
Instance size: the sizing of the RDS instance depends on the number of Metabase instances that will be connected to this database, the number of simultaneous users who are using Metabase, and the number of questions, dashboards, and configurations that are saved. To start, a `t3.small` is a good choice.
![RDS Instance size](images/RDSInstanceSize.png)
- Availability & Durability: on production deployments, you **should** be using a Multi-AZ (Availability Zone) cluster, as this will ensure that the database does not goes down in case there is an issue on a single availability zone.
Availability & Durability: on production deployments, you **should** be using a Multi-AZ (Availability Zone) cluster, as this will ensure that the database does not goes down in case there is an issue on a single availability zone.
![RDS MultiAZ](images/RDSMultiAZ.png)
- Connectivity:
Connectivity:
- Ensure that you are deploying the database in the same VPC as the one you deployed the Metabase instance/s, otherwise they won't be able to see each other.
- Create a **VPC security group**, as you will need to grant access from the Metabase instance/s to the database on the port that listens for connections.
- Ensure that you are deploying the database in the same VPC as the one you deployed the Metabase instance/s, otherwise they won't be able to see each other.
- Create a **VPC security group**, as you will need to grant access from the Metabase instance/s to the database on the port that listens for connections.
![RDS VPC Security Groups](images/RDSVPCSecurityGroup.png)
- Additional configuration
- Enter `metabase` as the **Initial database name**. Metabase will use this database for all of its configurations.
- You can also configure the backup window in case you need to restore the backups at some point in time.
![RDS Initial Database](images/RDSInitialDatabase.png)
Additional configuration:
- Enter `metabase` as the **Initial database name**. Metabase will use this database for all of its configurations.
- You can also configure the backup window in case you need to restore the backups at some point in time.
![RDS Initial Database](images/RDSInitialDatabase.png)
When you've completed all these configurations, click on the **Create database** button on the lower right part of the page and wait for the database to be created (which can take several minutes).
## Step 3
## Set up security
Once the database status is `Available`, you need to click on the DB identifier:
![RDS DB Identifier](images/RDSDBIdentifier.png)
On the page that appears after you click on the database identifer, you will see on the center of the page the **Connectivity & Security** section. This section will provide you with the **Endpoint** that Metabase needs to connect to the application database we just created.
![RDS Connection Data](images/RDSConnectionData.png)
In the **Security group rules** section, you'll see the Security Group that was created, but the group will have a rule that allows only one IP address to access the database. You need to change this rule to allow access to the Elastic Beanstalk environment.
In the **Security group rules** section, you'll see the Security Group that was created, but the group will have a rule that allows only one IP address to access the database.
![RDS Security Group Rules](images/RDSSecurityGroupRules.png)
To configure the rule for the database, select the **CIDR/IP - Inbound** rule, then click on the **Inbound rules** tab on the lower part of the page.
......@@ -62,42 +67,10 @@ When you click on Inbound Rules, you need to click on **Edit Inbound Rules** but
![RDS Edit Inbound Rule](images/RDSEditInboundRule.png)
On the edit page, you need to delete the IP address that appears as default, then add the security group that the Elastic Beanstalk has (the Security group name will have the keyword AWSEBSecurityGroup in its name). Once you add this security group, click the **Save rules** button.
On the edit page, you need to delete the IP address that appears as default, then add the security group for the server you're running Metabase on (the Security group name will have the keyword AWSEBSecurityGroup in its name). Once you add this security group, click the **Save rules** button.
![RDS Edit Inbound Rule](images/RDSEditInboundRuleSG.png)
## Step 4
After having finished all the previous steps, go to the your Elastic Beanstalk deployment and add the RDS instance as the Application Database with [Environment variables](../configuring-metabase/environment-variables.md) under the [Software configuration](running-metabase-on-elastic-beanstalk.md#set-or-change-environment-variables).
## Decouple your RDS database from the Elastic Beanstalk deployment
In the previous versions of this guide, we recommended the creation of an Elastic Beanstalk deployment (AWS's service for deploying applications easily) that had a RDS (AWS's Relational Database Service) database included in the creation by default thanks to the magic of CloudFormation (AWS's Infrastructure as a Code service). While this was an easier approach to simplify the deployments, we found out that this approach was not the optimal for building a future-proof architecture, since leaving the creation of the database to Elastic Beanstalk lead to limitations in the configuration of the database that would limit the choice for users. That's the reason why we now recommend creating the database separately from the Metabase deployment and glue them together manually, or even separate both components with this guide:
- This procedure will generate downtime, so make sure to communicate to your users that Metabase will be down while you recreate the environment with the new database.
- You'll need the master username and password for the database you used when you created the Elastic Beanstalk instance.
### Step 1
Identify the RDS endpoint that your Elastic Beanstalk is using by going to the configuration of the Environment and finding the endpoint value on the Database section.
![RDS endpooint](images/EBDatabaseEndpoint.png)
- If the Retention option is "Create snapshot", you're good to go. You can delete the whole Elastic Beanstalk environment, because AWS will take a snapshot (backup) of the database before deleting the environment.
- In case the Retention option has a different value, visit your RDS instance and take a snapshot of the database used by the Elastic Beanstalk application.
![RDS snapshot](images/RDSTakeSnapshot.png)
### Step 2
Go to the Elastic Beanstalk Metabase Application, select the running environment, and terminate it. Confirm that the database will be terminated **with snapshot**)
![Terminate environment](images/EBTerminateEnvironment.png)
This step can take around 20 minutes. If the deletion fails, you'll have to identify through CloudFormation which resources failed to be deleted and delete them yourself.
### Step 3
Return to RDS and select the **Snapshots** option on the left of the page. You should see a Manual Snapshot listed.
![RDS Snapshots](images/RDSSnapshotsMenu.png)
Select that snapshot and click on **Actions** → Restore Snapshot.
## Add the RDS instance as the application database with environment variables
From this step on, you can follow the same steps as the [Configuring RDS for Metabase](#configuring-rds-for-metabase) from [step 2](#step-2).
After having finished all the previous steps, go to the your Metabase deployment and add the RDS instance as the Application Database with [Environment variables](../configuring-metabase/environment-variables.md).
\ No newline at end of file
......@@ -32,7 +32,6 @@ To run a development branch of Metabase, check out our [developer's guide](../de
## Other installation options
- [Running on AWS Elastic Beanstalk](running-metabase-on-elastic-beanstalk.md)
- [Running on Azure Web Apps](running-metabase-on-azure.md)
- [Running on Debian as a service](running-metabase-on-debian.md)
......
......@@ -15,7 +15,7 @@ Metabase ships with an embedded H2 application database that you should avoid us
If you want to run Metabase in production, you'll need to use a production-ready application database to store your application data. You can switch from using the default H2 application database at any time, but if you're planning on running Metabase in production, the sooner you migrate to a production application database, the better. If you keeping running Metabase with the default H2 application database, and you don't regularly back it up, the application database could get corrupted, and you could end up losing all of your questions, dashboards, collections, and other Metabase data.
The migration process is a one-off process. You can execute the migration script from any computer that has the H2 application database file. For example, if you're trying to migrate from the H2 database to a setup that uses AWS Elastic Beanstalk to run Metabase with an RDS database as the application database, you can run the migration from your computer instead of trying to cram the H2 file into your Elastic Beanstalk.
The migration process is a one-off process. You can execute the migration script from any computer that has the H2 application database file.
### Avoid migrating and upgrading at the same time
......
......@@ -28,8 +28,6 @@ We recommend that you deploy Metabase using a service and cloud provider that yo
- [Running on Azure Web Apps](running-metabase-on-azure.md)
- [Running on Debian as a service](running-metabase-on-debian.md)
- [Running on AWS Elastic Beanstalk](running-metabase-on-elastic-beanstalk.md)
- [Advanced topics for running on AWS Elastic Beanstalk](./advanced-topics-for-running-Metabase-in-AWS-ElasticBeanstalk.md)
## [Building Metabase from source](../developers-guide/start.md)
......
......@@ -133,7 +133,6 @@ If you're on a [Metabase Cloud](https://www.metabase.com/pricing) plan, your Met
## Upgrading Metabase on other platforms
- [Upgrading AWS Elastic Beanstalk deployments](running-metabase-on-elastic-beanstalk.md#deploying-new-versions-of-metabase-on-elastic-beanstalk)
- [Upgrading Azure Web Apps deployments](running-metabase-on-azure.md#additional-configurations)
## Rolling back an upgrade
......
......@@ -12,7 +12,7 @@ If the bug has not yet been reported, go ahead and [open a bug report][metabase-
2. Javascript console logs
3. Whether it can be reproduced on the sample database
4. Your Metabase version
5. Where Metabase is running (Docker image, AWS Elastic Beanstalk, Heroku, Linux/Ubuntu, etc.)
5. Where Metabase is running (Docker image, Linux/Ubuntu, etc.)
6. Which database you are using
7. What browser version you are using
8. Screenshots (if relevant)
......
......@@ -78,7 +78,7 @@ Docker logs -f CONTAINER_ID
will let you see the logs as they are printed.
If the container is being terminated before it finished starting, the problem could be a health check timeout in the orchestration service used to start the container, such as Docker Cloud or Elastic Beanstalk.
If the container is being terminated before it finished starting, the problem could be a health check timeout in the orchestration service used to start the container, such as Docker Cloud.
If the container is _not_ being terminated from the outside, but is failing to start anyway, this problem is probably not specific to Docker. If you're using a Metabase-supplied image, please [open a GitHub issue](https://github.com/metabase/metabase/issues/new/choose).
......
......@@ -10,7 +10,7 @@ If your queries are hanging or timing out, the problem could be coming from your
- Load balancer
- Reverse proxy server (e.g., Nginx)
- Jetty
- Cloud service (such as AWS’s Elastic Beanstalk, EC2, Heroku, or Google App Engine).
- Cloud service
## Resources for common deployments
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment