

# Using the Elastic Beanstalk .NET core on Linux platform
<a name="dotnet-linux-platform"></a>

This topic describes how to configure, build, and run your .NET core on Linux applications on Elastic Beanstalk.

AWS Elastic Beanstalk supports a number of platform branches for different .NET Core framework versions that run on the Linux operating system. See [.NET core on Linux ](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.dotnetlinux) in the *AWS Elastic Beanstalk Platforms* for a full list.

For details about the various ways you can extend an Elastic Beanstalk Linux-based platform, see [Extending Elastic Beanstalk Linux platforms](platforms-linux-extend.md). 

## .NET Core on Linux platform considerations
<a name="dotnet-linux-platform.intro"></a>

### Proxy server
<a name="dotnet-linux-platform.proxy"></a>

The Elastic Beanstalk .NET Core on Linux platform includes a reverse proxy that forwards requests to your application. By default, Elastic Beanstalk uses [NGINX](https://www.nginx.com/) as the proxy server. You can choose to use no proxy server, and configure [Kestrel](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel) as your web server. Kestrel is included by default in ASP.NET Core project templates.

### Application structure
<a name="dotnet-linux-platform.publish-apps"></a>

You can publish *runtime-dependent* applications that use the .NET Core runtime provided by Elastic Beanstalk. You can also publish *self-contained* applications that include the .NET Core runtime and your application's dependencies in the source bundle. To learn more, see [Bundling applications for the .NET Core on Linux Elastic Beanstalk platform](dotnet-linux-platform-bundle-app.md).

### Platform configuration
<a name="dotnet-linux-platform.configuration"></a>

To configure the processes that run on the server instances in your environment, include an optional [Procfile](dotnet-linux-procfile.md) in your source bundle. A `Procfile` is required if you have more than one application in your source bundle.

We recommend that you always provide a `Procfile` in the source bundle with your application. This way you precisely control which processes Elastic Beanstalk runs for your application.

Configuration options are available in the Elastic Beanstalk console for [modifying the configuration of a running environment](environment-configuration-methods-after.md). To avoid losing your environment's configuration when you terminate it, you can use [saved configurations](environment-configuration-savedconfig.md) to save your settings and later apply them to another environment.

To save settings in your source code, you can include [configuration files](ebextensions.md). Settings in configuration files are applied every time you create an environment or deploy your application. You can also use configuration files to install packages, run scripts, and perform other instance customization operations during deployments.

Settings applied in the Elastic Beanstalk console override the same settings in configuration files, if they exist. This lets you have default settings in configuration files, and override them with environment-specific settings in the console. For more information about precedence, and other methods of changing settings, see [Configuration options](command-options.md).

## Configuring your .NET Core on Linux environment
<a name="dotnet-linux-options"></a>

The .NET Core on Linux platform settings enable you to fine-tune the behavior of your Amazon EC2 instances. You can edit the Elastic Beanstalk environment's Amazon EC2 instance configuration using the Elastic Beanstalk console.

Use the Elastic Beanstalk console to enable log rotation to Amazon S3 and configure variables that your application can read from the environment.

**To configure your .NET Core on Linux environment using the Elastic Beanstalk console**

1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.

1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list.

1. In the navigation pane, choose **Configuration**.

1. In the **Updates, monitoring, and logging** configuration category, choose **Edit**.

### Log options
<a name="dotnet-linux-logs"></a>

The **Log Options** section has two settings:
+ **Instance profile** – Specifies the instance profile that has permission to access the Amazon S3 bucket associated with your application.
+ **Enable log file rotation to Amazon S3** – Specifies whether log files for your application's Amazon EC2 instances are copied to the Amazon S3 bucket associated with your application.

### Environment properties
<a name="dotnet-linux-options-properties"></a>

The **Environment Properties** section enables you to specify environment configuration settings on the Amazon EC2 instances that are running your application. Environment properties are passed in as key-value pairs to the application.

Inside the .NET Core on Linux environment running in Elastic Beanstalk, environment variables are accessible using `Environment.GetEnvironmentVariable("variable-name")`. For example, you could read a property named `API_ENDPOINT` to a variable with the following code.

```
string endpoint = Environment.GetEnvironmentVariable("API_ENDPOINT");
```

See [Environment variables and other software settings](environments-cfg-softwaresettings.md) for more information.

## .NET Core on Linux configuration namespace
<a name="dotnet-linux-namespace"></a>

You can use a [configuration file](ebextensions.md) to set configuration options and perform other instance configuration tasks during deployments. Configuration options can be [platform specific](command-options-specific.md) or apply to [all platforms](command-options-general.md) in the Elastic Beanstalk service as a whole. Configuration options are organized into *namespaces*.

The .NET Core on Linux platform supports options in the following namespace, in addition to the [options supported for all Elastic Beanstalk environments](command-options-general.md):
+ `aws:elasticbeanstalk:environment:proxy` – Choose to use NGINX or no proxy server. Valid values are `nginx` or `none`.

The following example configuration file shows the use of the .NET Core on Linux-specific configuration options. 

**Example .ebextensions/proxy-settings.config**  

```
option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none
```

Elastic Beanstalk provides many configuration options for customizing your environment. In addition to configuration files, you can also set configuration options using the console, saved configurations, the EB CLI, or the AWS CLI. See [Configuration options](command-options.md) for more information.

# Bundling applications for the .NET Core on Linux Elastic Beanstalk platform
<a name="dotnet-linux-platform-bundle-app"></a>

You can run both *runtime-dependent* and *self-contained* .NET Core applications on AWS Elastic Beanstalk.

A runtime-dependent application uses a .NET Core runtime that Elastic Beanstalk provides to run your application. Elastic Beanstalk uses the `runtimeconfig.json` file in your source bundle to determine the runtime to use for your application. Elastic Beanstalk chooses the latest compatible runtime available for your application.

A self-contained application includes the .NET Core runtime, your application, and its dependencies. To use a version of the .NET Core runtime that Elastic Beanstalk doesn't include in its platforms, provide a self-contained application.

## Examples
<a name="dotnet-linux-platform-bundle-app-examples"></a>

You can compile both self-contained and runtime-dependent applications with the `dotnet publish` command. To learn more about publishing .NET Core apps, see [.NET Core application publishing overview](https://docs.microsoft.com/en-us/dotnet/core/deploying) in the .NET Core documentation.

The following example file structure defines a single application that uses a .NET Core runtime that Elastic Beanstalk provides.

```
├── appsettings.Development.json
├── appsettings.json
├── dotnetcoreapp.deps.json
├── dotnetcoreapp.dll
├── dotnetcoreapp.pdb
├── dotnetcoreapp.runtimeconfig.json
├── web.config
├── Procfile
├── .ebextensions
├── .platform
```

You can include multiple applications in your source bundle. The following example defines two applications to run on the same web server. To run multiple applications, you must include a [Procfile](dotnet-linux-procfile.md) in your source bundle. For a full example application, see [dotnet-core-linux-multiple-apps.zip](samples/dotnet-core-linux-multiple-apps.zip).

```
├── DotnetMultipleApp1
│   ├── Amazon.Extensions.Configuration.SystemsManager.dll
│   ├── appsettings.Development.json
│   ├── appsettings.json
│   ├── AWSSDK.Core.dll
│   ├── AWSSDK.Extensions.NETCore.Setup.dll
│   ├── AWSSDK.SimpleSystemsManagement.dll
│   ├── DotnetMultipleApp1.deps.json
│   ├── DotnetMultipleApp1.dll
│   ├── DotnetMultipleApp1.pdb
│   ├── DotnetMultipleApp1.runtimeconfig.json
│   ├── Microsoft.Extensions.PlatformAbstractions.dll
│   ├── Newtonsoft.Json.dll
│   └── web.config
├── DotnetMultipleApp2
│   ├── Amazon.Extensions.Configuration.SystemsManager.dll
│   ├── appsettings.Development.json
│   ├── appsettings.json
│   ├── AWSSDK.Core.dll
│   ├── AWSSDK.Extensions.NETCore.Setup.dll
│   ├── AWSSDK.SimpleSystemsManagement.dll
│   ├── DotnetMultipleApp2.deps.json
│   ├── DotnetMultipleApp2.dll
│   ├── DotnetMultipleApp2.pdb
│   ├── DotnetMultipleApp2.runtimeconfig.json
│   ├── Microsoft.Extensions.PlatformAbstractions.dll
│   ├── Newtonsoft.Json.dll
│   └── web.config
├── Procfile
├── .ebextensions
├── .platform
```

# Using a Procfile to configure your .NET Core on Linux Elastic Beanstalk environment
<a name="dotnet-linux-procfile"></a>

To run multiple applications on the same web server, you must include a `Procfile` in your source bundle that tells Elastic Beanstalk which applications to run.

We recommend that you always provide a `Procfile` in the source bundle with your application. This way you precisely control which processes Elastic Beanstalk runs for your application and which arguments these processes receive.

The following example uses a `Procfile` to specify two applications for Elastic Beanstalk to run on the same web server.

**Example Procfile**  

```
web: dotnet ./dotnet-core-app1/dotnetcoreapp1.dll
web2: dotnet ./dotnet-core-app2/dotnetcoreapp2.dll
```

For details about writing and using a `Procfile`, see [Buildfile and Procfile](platforms-linux-extend.build-proc.md).

# Configuring the proxy server
<a name="dotnet-linux-platform-nginx"></a>

AWS Elastic Beanstalk uses [NGINX](https://www.nginx.com/) as the reverse proxy to relay requests to your application. Elastic Beanstalk provides a default NGINX configuration that you can either extend or override completely with your own configuration.

By default, Elastic Beanstalk configures the NGINX proxy to forward requests to your application on port 5000. You can override the default port by setting the `PORT` [environment property](dotnet-linux-platform.md#dotnet-linux-options-properties) to the port on which your main application listens.

**Note**  
The port that your application listens on doesn't affect the port that the NGINX server listens on to receive requests from the load balancer.

**Configuring the proxy server on your platform version**  
All AL2023/AL2 platforms support a uniform proxy configuration feature. For more information about configuring the proxy server on your platform versions running AL2023/AL2, see [Reverse proxy configuration](platforms-linux-extend.proxy.md). 

The following example configuration file extends your environment's NGINX configuration. The configuration directs requests to `/api` to a second web application that listens on port 5200 on the web server. By default, Elastic Beanstalk forwards requests to a single application that listens on port 5000.

**Example `01_custom.conf`**  

```
location /api {
     proxy_pass          http://127.0.0.1:5200;
     proxy_http_version  1.1;

     proxy_set_header   Upgrade $http_upgrade;
     proxy_set_header   Connection $http_connection;
     proxy_set_header   Host $host;
     proxy_cache_bypass $http_upgrade;
     proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header   X-Forwarded-Proto $scheme;
}
```