# Elastic Beanstalk Linux platforms Linux platforms The Elastic Beanstalk Linux platforms provide an extensive amount of functionality out of the box. You can extend the platforms in several ways to support your application. For details, see [Extending Elastic Beanstalk Linux platforms](platforms-linux-extend.md). Most of the platforms that Elastic Beanstalk supports are based on the Linux operating system. Specifically, these platforms are based on Amazon Linux, a Linux distribution provided by AWS. Elastic Beanstalk Linux platforms use Amazon Elastic Compute Cloud (Amazon EC2) instances, and these instances run Amazon Linux. **Topics** + [ ## Supported Amazon Linux versions ](#platforms-linux.versions) + [ ## List of Elastic Beanstalk Linux platforms ](#platforms-linux.list) + [ # Instance deployment workflow ](platforms-linux-extend.workflow.md) + [ # Instance deployment workflow for ECS running on Amazon Linux 2 and later ](platforms-linux-extend.workflow.ecs-al2.md) + [ # Platform script tools for your Elastic Beanstalk environments ](custom-platforms-scripts.md) ## Supported Amazon Linux versions AWS Elastic Beanstalk supports platforms based on Amazon Linux 2 and Amazon Linux 2023. For more information about Amazon Linux 2 and Amazon Linux 2023, see the following: + **Amazon Linux 2** – [Amazon Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html) in the *Amazon EC2 User Guide*. + **Amazon Linux 2023** – [What is Amazon Linux 2023?](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) in the *Amazon Linux 2023 User Guide* For details about supported platform versions, see [Elastic Beanstalk supported platforms](concepts.platforms.md). **Note** You can migrate your application from an Elastic Beanstalk AL1 or AL2 platform branch to the equivalent AL2023 platform branch. For more information, see [Migrating your Elastic Beanstalk Linux application to Amazon Linux 2023 or Amazon Linux 2](using-features.migration-al.md). ### Amazon Linux 2023 AWS announced the [general availability](https://aws.amazon.com//blogs/aws/amazon-linux-2023-a-cloud-optimized-linux-distribution-with-long-term-support/) of Amazon Linux 2023 in March of 2023. The *Amazon Linux 2023 User Guide* summarizes key differences between Amazon Linux 2 and Amazon Linux 2023. For more information, see [Comparing Amazon Linux 2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) in the user guide. There is a high degree of compatibility between Elastic Beanstalk Amazon Linux 2 and Amazon Linux 2023 platforms. Although there are some differences to note: + **Instance Metadata Service Version 1 (IMDSv1)** – The [DisableIMDSv1](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) option setting defaults to `true` on AL2023 platforms. The default is `false` on AL2 platforms. + **pkg-repo instance tool** – The [pkg-repo](custom-platforms-scripts.md#custom-platforms-scripts.pkg-repo) tool is not available for environments running on AL2023 platforms. However, you can still manually apply package and operating system updates to an AL2023 instance. For more information, see [Managing packages and operating system updates](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) in the *Amazon Linux 2023 User Guide*. + **Apache HTTPd configuration** – The Apache `httpd.conf` file for AL2023 platforms has some configuration settings that are different from those for AL2: + Deny access to the server’s entire file system by default. These settings are described in *Protect Server Files by Default* on the Apache website [Security Tips](https://httpd.apache.org/docs/2.4/misc/security_tips.html) page. + Deny access to set up of `.htaccess` in all directories, except for those specifically enabled. This setting is described in *Protecting System Settings* on the Apache website [Security Tips](https://httpd.apache.org/docs/2.4/misc/security_tips.html) page. The [Apache HTTP Server Tutorial: .htaccess files ](https://httpd.apache.org/docs/2.4/howto/htaccess.html) page states this setting may help improve performance. + Deny access to files with name pattern `.ht*`. This setting prevents web clients from viewing `.htaccess` and `.htpasswd` files. You can change any of the above configuration settings for your environment. For more information, see [Configuring Apache HTTPD](platforms-linux-extend.proxy.md#platforms-linux-extend.proxy.httpd). + **Multiline environment variable support** – AL2023 platforms support multiline values for environment variables and secrets in systemd service configurations. Amazon Linux 2 platforms do not support multiline environment variable values. This enhancement allows you to use multiline secrets and configuration values on AL2023 platforms. For more information about using environment variables and secrets, see [Multiline values in Amazon Linux 2 environment variables](AWSHowTo.secrets.env-vars.md#AWSHowTo.secrets.multiline). + **CloudWatch custom log forwarding** – The deprecated CloudWatch Logs agent (`awslogs` package) is not available on AL2023 platforms. If you have custom log forwarding configurations that install and use the deprecated `awslogs` agent, you must update your configuration files to use the unified CloudWatch agent when migrating from Amazon Linux 2 to AL2023. For more information, see [Custom log file streaming](AWSHowTo.cloudwatchlogs.md#AWSHowTo.cloudwatchlogs.streaming.custom). **Platform-specific differences** In addition to the base operating system differences, there are platform-specific differences between Amazon Linux 2 and AL2023 runtime platforms: + **.NET platform branching** – The .NET platform branching strategy differs between Amazon Linux 2 and AL2023. On Amazon Linux 2, the .NET Core platform maintains a rotating window of .NET major versions within a single platform branch. On AL2023, each platform branch is pinned to a specific .NET major version (for example, .NET 9, .NET 10). If you deploy framework-dependent applications (applications that rely on the platform's installed .NET runtime), you must select a platform branch that matches your application's target .NET version. If you deploy self-contained applications (applications that bundle their own .NET runtime), you can use any AL2023 .NET platform branch regardless of your application's .NET version, as your application is not dependent on the platform's installed runtime. For more information, see [Bundling applications for the .NET Core on Linux Elastic Beanstalk platform](dotnet-linux-platform-bundle-app.md). + **Node.js version selection** – The Node.js platform on Amazon Linux 2 supports specifying a Node.js version in your application's `package.json` file. The Node.js platform on AL2023 does not support this feature. You must use the default Node.js version provided by the platform branch. For more information about Node.js version management, see [Configuring your application's dependencies on Elastic Beanstalk](nodejs-platform-dependencies.md). + **Ruby Puma server version** – The Ruby platform on Amazon Linux 2 ignores the Puma version specified in your application's `Gemfile.lock` file and uses the platform default Puma version. The Ruby platform on AL2023 honors the Puma version specified in `Gemfile.lock` if present. If no version is specified, the platform installs the platform default Puma version. + **PHP package availability** – Some packages available on Amazon Linux 2 PHP platforms are not available on AL2023 PHP platforms: + *MySQL client packages* – The `mysql` and `mysql-devel` command-line client packages are not installed on AL2023 PHP platforms. If your application requires MySQL database connectivity, use the PHP `mysqli` or `pdo_mysql` extensions, which are available on both platforms. + *Compass and Ruby tools* – The `ruby-devel` and `rubygems` packages for Compass CSS framework support are not installed on AL2023 PHP platforms. Compass has been deprecated. Consider using modern CSS preprocessing tools as alternatives. + **Go version control tools** – The Bazaar version control system (`bzr`) is not available on AL2023 Go platforms. Bazaar is deprecated and not included in the AL2023 package repository. Use Git, Mercurial, or Subversion for version control instead, all of which are available on AL2023 Go platforms. ## List of Elastic Beanstalk Linux platforms The following list provides the Linux platforms that Elastic Beanstalk supports for different programming languages as well as for Docker containers. Elastic Beanstalk offers platforms based on Amazon Linux 2 and Amazon Linux 2023 for all of them. To learn more about a platform, select the corresponding link. + [Docker (and ECS Docker)](create_deploy_docker.md) + [Go](create_deploy_go.md) + [Tomcat (running Java SE)](create_deploy_Java.md) + [Java SE](create_deploy_Java.md) + [.NET Core on Linux](create-deploy-dotnet-core-linux.md) + [Node.js](create_deploy_nodejs.md) + [PHP](create_deploy_PHP_eb.md) + [Python](create-deploy-python-apps.md) + [Ruby](create_deploy_Ruby.md) # Instance deployment workflow **Note** The information in this section doesn't apply to the *ECS running on Amazon Linux 2 and Amazon Linux 2023* platform branches. For more information, see the next section [Instance deployment workflow for ECS running on Amazon Linux 2 and laterInstance deployment workflow for ECS on AL2 and later](platforms-linux-extend.workflow.ecs-al2.md). With many ways to extend your environment's platform, it's useful to know what happens whenever Elastic Beanstalk provisions an instance or runs a deployment to an instance. The following diagram shows this entire deployment workflow. It depicts the different phases in a deployment and the steps that Elastic Beanstalk takes in each phase. **Notes** The diagram doesn't represent the complete set of steps that Elastic Beanstalk takes on environment instances during deployment. We provide this diagram for illustration, to provide you with the order and context for the execution of your customizations. For simplicity, the diagram mentions only the `.platform/hooks/*` hook subdirectories (for application deployments), and not the `.platform/confighooks/*` hook subdirectories (for configuration deployments). Hooks in the latter subdirectories run during exactly the same steps as hooks in corresponding subdirectories shown in the diagram. ![\[Workflow for extensions execution order on an environment instance running on a Amazon Linux-based platform.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/platforms-linux-extend-order.png) The following list details the deployment phases and steps. 1. **Initial steps** Elastic Beanstalk downloads and extracts your application. After each one of these steps, Elastic Beanstalk runs one of the extensibility steps. 1. Runs commands found in the [commands:](customize-containers-ec2.md#linux-commands) section of any configuration file. 1. Runs any executable files found in the `.platform/hooks/prebuild` directory of your source bundle (`.platform/confighooks/prebuild` for a configuration deployment). 1. **Configure** Elastic Beanstalk configures your application and the proxy server. 1. Runs the commands found in the `Buildfile` in your source bundle. 1. Copies your custom proxy configuration files, if you have any in the `.platform/nginx` directory of your source bundle, to their runtime location. 1. Runs commands found in the [container\$1commands:](customize-containers-ec2.md#linux-container-commands) section of any configuration file. 1. Runs any executable files found in the `.platform/hooks/predeploy` directory of your source bundle (`.platform/confighooks/predeploy` for a configuration deployment). 1. **Deploy** Elastic Beanstalk deploys and runs your application and the proxy server. 1. Runs the command found in the `Procfile` file in your source bundle. 1. Runs or reruns the proxy server with your custom proxy configuration files, if you have any. 1. Runs any executable files found in the `.platform/hooks/postdeploy` directory of your source bundle (`.platform/confighooks/postdeploy` for a configuration deployment). # Instance deployment workflow for ECS running on Amazon Linux 2 and later Instance deployment workflow for ECS on AL2 and later The previous section describes the supported extensibility features throughout the phases of the application deployment workflow. There are some differences for the Docker platform branches [*ECS running on Amazon Linux 2 and later*](create_deploy_docker_ecs.md). This section explains how those concepts apply to this specific platform branch. With many ways to extend your environment's platform, it's useful to know what happens whenever Elastic Beanstalk provisions an instance or runs a deployment to an instance. The following diagram shows this entire deployment workflow for an environment based on the *ECS running on Amazon Linux 2* and *ECS running on Amazon Linux 2023* platform branches. It depicts the different phases in a deployment and the steps that Elastic Beanstalk takes in each phase. Unlike the workflow described in the prior section, the deployment Configuration phase doesn't support the following extensibility features: `Buildfile` commands, `Procfile` commands, reverse proxy configuration. **Notes** The diagram doesn't represent the complete set of steps that Elastic Beanstalk takes on environment instances during deployment. We provide this diagram for illustration, to provide you with the order and context for the execution of your customizations. For simplicity, the diagram mentions only the `.platform/hooks/*` hook subdirectories (for application deployments), and not the `.platform/confighooks/*` hook subdirectories (for configuration deployments). Hooks in the latter subdirectories run during exactly the same steps as hooks in corresponding subdirectories shown in the diagram. ![\[Workflow for extensions execution order on an environment instance on the ECS-based Docker platform.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/platform-ecs-al2-extended-order.png) The following list details the deployment workflow steps. 1. Runs any executable files found in the `appdeploy/pre` directory under `EBhooksDir`. 1. Runs any executable files found in the `.platform/hooks/prebuild` directory of your source bundle (`.platform/confighooks/prebuild` for a configuration deployment). 1. Runs any executable files found in the `.platform/hooks/predeploy` directory of your source bundle (`.platform/confighooks/predeploy` for a configuration deployment). 1. Runs any executable files found in the `appdeploy/enact` directory under `EBhooksDir`. 1. Runs any executable files found in the `appdeploy/post` directory under `EBhooksDir`. 1. Runs any executable files found in the `.platform/hooks/postdeploy` directory of your source bundle (`.platform/confighooks/postdeploy` for a configuration deployment). The reference to `EBhooksDir` represents the path of the platform hooks directory. To retrieve directory path name use the [get-config](custom-platforms-scripts.md#custom-platforms-scripts.get-config) script tool on the command line of your environment instance as shown: ``` $ /opt/elasticbeanstalk/bin/get-config platformconfig -k EBhooksDir ``` # Platform script tools for your Elastic Beanstalk environments Platform script tools This topic describes tools that AWS Elastic Beanstalk provides for environments that use Amazon Linux platforms. The tools are located on the Amazon EC2 instances of the Elastic Beanstalk environments. ## get-config Use the `get-config` tool to retrieve plain text environment variable values and other platform and instance information. The tool is available at `/opt/elasticbeanstalk/bin/get-config`. ### get-config commands Each `get-config` tool command returns a specific type of information. Use the following syntax to run the commands of any of the tools. ``` $ /opt/elasticbeanstalk/bin/get-config command [ options ] ``` The following example runs the `environment` command. ``` $ /opt/elasticbeanstalk/bin/get-config environment -k PORT ``` Depending on the command and options you choose, the tool returns an object (JSON or YAML) with key-value pairs or a single value. You can test `get-config` by using SSH to connect to an EC2 instance in your Elastic Beanstalk environment. **Note** When you run `get-config` for testing, some commands might require root user privileges to access the underlying information. If you get an access permission error, run the command again under `sudo`. You don't need to add `sudo` when using the tool in the scripts that you deploy to your environment. Elastic Beanstalk runs all your scripts as the root user. The following sections describe the commands for the tools. #### optionsettings – Configuration options The `get-config optionsettings` command returns an object that's listing the configuration options that are set on the environment and used by the platform on environment instances. They're organized by namespace. ``` $ /opt/elasticbeanstalk/bin/get-config optionsettings {"aws:elasticbeanstalk:application:environment":{"JDBC_CONNECTION_STRING":""},"aws:elasticbeanstalk:container:tomcat:jvmoptions":{"JVM Options":"","Xms":"256m","Xmx":"256m"},"aws:elasticbeanstalk:environment:proxy":{"ProxyServer":"nginx","StaticFiles":[""]},"aws:elasticbeanstalk:healthreporting:system":{"SystemType":"enhanced"},"aws:elasticbeanstalk:hostmanager":{"LogPublicationControl":"false"}} ``` To return a specific configuration option value, use the `--namespace` (`-n`) option to specify a namespace, and the `--option-name` (`-o`) option to specify an option name. ``` $ /opt/elasticbeanstalk/bin/get-config optionsettings -n aws:elasticbeanstalk:container:php:phpini -o memory_limit 256M ``` #### environment – Environment properties The `get-config environment` command returns an object containing a list of environment properties, including both user-configured and provided by Elastic Beanstalk. The user-configured properties are defined in the [console](environments-cfg-softwaresettings.md#environments-cfg-softwaresettings-console) as *Plain text* or with the configuration option namespace [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment). ``` $ /opt/elasticbeanstalk/bin/get-config environment {"JDBC_CONNECTION_STRING":"","RDS_PORT":"3306","RDS_HOSTNAME":"anj9aw1b0tbj6b.cijbpanmxz5u.us-west-2.rds.amazonaws.com","RDS_USERNAME":"testusername","RDS_DB_NAME":"ebdb","RDS_PASSWORD":"testpassword1923851"} ``` For example, Elastic Beanstalk provides environment properties for connecting to an integrated Amazon RDS DB instance (for example, `RDS_HOSTNAME`). These RDS connection properties appear in the output of `get-config environment`. However, they don't appear in the output of `get-config optionsettings`. This is because they weren't set in configuration options. To return a specific environment property, use the `--key` (`-k`) option to specify a property key. ``` $ /opt/elasticbeanstalk/bin/get-config environment -k TESTPROPERTY testvalue ``` **Note** The `get-config` tool cannot retrieve [environment variables that store secrets](AWSHowTo.secrets.env-vars.md). For more information about how to programmatically retrieve values from secret or parameter stores, see [Using Secrets Manager](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.Secrets-Manager) or [Using Systems Manager Parameter Store](AWSHowTo.secrets.Secrets-Manager-and-Parameter-Store.md#AWSHowTo.secrets.SSM-parmameter-store). #### container – On-instance configuration values The `get-config container` command returns an object that lists platform and environment configuration values for environment instances. The following example shows the output for the command on an Amazon Linux 2 Tomcat environment. ``` $ /opt/elasticbeanstalk/bin/get-config container {"common_log_list":["/var/log/eb-engine.log","/var/log/eb-hooks.log"],"default_log_list":["/var/log/nginx/access.log","/var/log/nginx/error.log"],"environment_name":"myenv-1da84946","instance_port":"80","log_group_name_prefix":"/aws/elasticbeanstalk","proxy_server":"nginx","static_files":[""],"xray_enabled":"false"} ``` To return the value of a specific key, use the `--key` (`-k`) option to specify the key. ``` $ /opt/elasticbeanstalk/bin/get-config container -k environment_name myenv-1da84946 ``` #### addons – Add-on configuration values The `get-config addons` command returns an object that contains configuration information of environment add-ons. Use it to retrieve the configuration of an Amazon RDS database that's associated with the environment. ``` $ /opt/elasticbeanstalk/bin/get-config addons {"rds":{"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}}} ``` You can restrict the result in two ways. To retrieve values for a specific add-on, use the `--add-on` (`-a`) option to specify the add-on name. ``` $ /opt/elasticbeanstalk/bin/get-config addons -a rds {"Description":"RDS Environment variables","env":{"RDS_DB_NAME":"ebdb","RDS_HOSTNAME":"ea13k2wimu1dh8i.c18mnpu5rwvg.us-east-2.rds.amazonaws.com","RDS_PASSWORD":"password","RDS_PORT":"3306","RDS_USERNAME":"user"}} ``` To return the value of a specific key within an add-on, add the `--key` (`-k`) option to specify the key. ``` $ /opt/elasticbeanstalk/bin/get-config addons -a rds -k RDS_DB_NAME ebdb ``` #### platformconfig – Constant configuration values The `get-config platformconfig` command returns an object that contains platform configuration information that's constant to the platform version. The output is the same on all environments that run the same platform version. The output object for the command has two embedded objects: + `GeneralConfig` – Contains information that's constant across the latest versions of all Amazon Linux 2 and Amazon Linux 2023 platform branches. + `PlatformSpecificConfig` – Contains information that's constant for the platform version and is specific to it. The following example shows the output for the command on an environment that uses the *Tomcat 8.5 running Corretto 11* platform branch. ``` $ /opt/elasticbeanstalk/bin/get-config platformconfig {"GeneralConfig":{"AppUser":"webapp","AppDeployDir":"/var/app/current/","AppStagingDir":"/var/app/staging/","ProxyServer":"nginx","DefaultInstancePort":"80"},"PlatformSpecificConfig":{"ApplicationPort":"8080","JavaVersion":"11","TomcatVersion":"8.5"}} ``` To return the value of a specific key, use the `--key` (`-k`) option to specify the key. These keys are unique across the two embedded objects. You don't need to specify the object that contains the key. ``` $ /opt/elasticbeanstalk/bin/get-config platformconfig -k AppStagingDir /var/app/staging/ ``` ### get-config output options Use the `--output` option to specify the output object format. Valid values are `JSON` (default) and `YAML`. This is a global option. You must specify it before the command name. The following example returns configuration option values in the YAML format. ``` $ /opt/elasticbeanstalk/bin/get-config --output YAML optionsettings aws:elasticbeanstalk:application:environment: JDBC_CONNECTION_STRING: "" aws:elasticbeanstalk:container:tomcat:jvmoptions: JVM Options: "" Xms: 256m Xmx: 256m aws:elasticbeanstalk:environment:proxy: ProxyServer: nginx StaticFiles: - "" aws:elasticbeanstalk:healthreporting:system: SystemType: enhanced aws:elasticbeanstalk:hostmanager: LogPublicationControl: "false" ``` ## pkg-repo **Note** The `pkg-repo` tool is not available for environments based on Amazon Linux 2023 platforms. However, you can manually apply package and operating system updates to an AL2023 instance. For more information, see [Managing packages and operating system updates](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) in the *Amazon Linux 2023 User Guide* In some urgent circumstances, you might need to update your Amazon EC2 instances with an Amazon Linux 2 security patch that hasn't yet been released with the required Elastic Beanstalk platform versions. You can't perform a manual update on your Elastic Beanstalk environments by default. This is because the platform versions are locked to a specific version of the Amazon Linux 2 repository. This lock ensures that instances run supported and consistent software versions. For urgent cases, the `pkg-repo` tool allows a workaround to manually update yum packages on Amazon Linux 2 if you need to install it on an environment before it's released in a new Elastic Beanstalk platform version. The `pkg-repo` tool on Amazon Linux 2 platforms provides the capability to unlock the `yum` package repositories. You can then manually perform a **yum update** for a security patch. Conversely, you can follow the update by using the tool to lock the yum package repositories to prevent further updates. The `pkg-repo` tool is available at the `/opt/elasticbeanstalk/bin/pkg-repo` directory of all the EC2 instances in your Elastic Beanstalk environments. Changes using the `pkg-repo` tool are made only on the EC2 instance that the tool is used on. They don’t affect other instances or prevent future updates to the environment. The examples that are provided later in this topic explain how to apply the changes across all instances by calling the `pkg-repo` commands from scripts and configuration files. **Warning** We don't recommend this tool for most users. Any manual changes applied to an unlocked platform version are considered out of band. This option is only viable for those users in urgent circumstances that can accept the following risks: Package versions can't be guaranteed to be consistent across all instances in your environments. Environments that are modified using the `pkg-repo` tool aren't guaranteed to function properly. They haven't been tested and verified on Elastic Beanstalk supported platforms. We strongly recommend applying best practices that include testing and backout plans. To help facilitate best practices, you can use the Elastic Beanstalk console and EB CLI to clone an environment and swap environment URLs. For more information about using these operations, see [Blue/Green deployments](using-features.CNAMESwap.md) in the *Managing environments* chapter of this guide. If you plan to manually edit yum repository configuration files, run the `pkg-repo` tool first. The `pkg-repo` tool might not work as intended in an Amazon Linux 2 environment with manually edited yum repository configuration files. This is because the tool might not recognize the configuration changes. For more information about the Amazon Linux package repository, see the [Package repository](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#package-repository) topic in the *Amazon EC2 User Guide*. ### pkg-repo commands Use the following syntax to run the `pkg-repo` tool commands. ``` $ /opt/elasticbeanstalk/bin/pkg-repo command [options] ``` The `pkg-repo` commands are the following: + **lock** – locks the `yum` package repositories to a specific version + **unlock** – unlocks the `yum` package repositories from a specific version + **status** – lists all the `yum` package repositories and their current lock status + **help** – shows general help or help for one command The options apply to the commands as follows: + `lock`, `unlock` and `status ` – options: `-h`, `--help`, or none (default). + `help` – options: `lock`, `unlock`, `status`, or none (default). The following example runs the **unlock** command. ``` $ sudo /opt/elasticbeanstalk/bin/pkg-repo unlock Amazon Linux 2 core package repo successfully unlocked Amazon Linux 2 extras package repo successfully unlocked ``` The following example runs the **lock** command. ``` $ sudo /opt/elasticbeanstalk/bin/pkg-repo lock Amazon Linux 2 core package repo successfully locked Amazon Linux 2 extras package repo successfully locked ``` The following example runs the **status** command. ``` $ sudo /opt/elasticbeanstalk/bin/pkg-repo status Amazon Linux 2 core package repo is currently UNLOCKED Amazon Linux 2 extras package repo is currently UNLOCKED ``` The following example runs the **help** command for the **lock** command. ``` $ sudo /opt/elasticbeanstalk/bin/pkg-repo help lock ``` The following example runs the **help** command for the `pkg-repo` tool. ``` $ sudo /opt/elasticbeanstalk/bin/pkg-repo help ``` You can test `pkg-repo` by using SSH to connect to an instance in your Elastic Beanstalk environment. One SSH option is the EB CLI [**eb ssh**](eb3-ssh.md) command. **Note** The `pkg-repo` tool requires root user privileges to run. If you get an access permission error, run the command again under `sudo`. You don't need to add `sudo` when using the tool in the scripts or configuration files that you deploy to your environment. Elastic Beanstalk runs all your scripts as the root user. ### pkg-repo examples The previous section provides command line examples for testing on an individual EC2 instance of an Elastic Beanstalk environment. This approach can be helpful for testing. However, it updates only one instance at a time, so it isn’t practical for applying changes to all of the instances in an environment. A more pragmatic approach is to use [platform hook](platforms-linux-extend.hooks.md) scripts or an [`.ebextensions`](ebextensions.md) configuration file to apply the changes across all instances in a consistent manner. The following example calls `pkg-repo` from a configuration file in the [`.ebextensions`](ebextensions.md) folder. Elastic Beanstalk runs the commands in the `update_package.config` file when you deploy your application source bundle. ``` .ebextensions └── update_package.config ``` To receive the latest version of the *docker* package, this configuration specifies the *docker* package in the **yum update** command. ``` ### update_package.config ### commands: update_package: command: | /opt/elasticbeanstalk/bin/pkg-repo unlock yum update docker -y /opt/elasticbeanstalk/bin/pkg-repo lock yum clean all -y rm -rf /var/cache/yum ``` This configuration doesn't specify any packages in the **yum update** command. All available updates are applied as a result. ``` ### update_package.config ### commands: update_package: command: | /opt/elasticbeanstalk/bin/pkg-repo unlock yum update -y /opt/elasticbeanstalk/bin/pkg-repo lock yum clean all -y rm -rf /var/cache/yum ``` The following example calls `pkg-repo` from a bash script as a [platform hook](platforms-linux-extend.hooks.md). Elastic Beanstalk runs the `update_package.sh` script file that's located in the `prebuild` subdirectory. ``` .platform └── hooks └── prebuild └── update_package.sh ``` To receive the latest version of the *docker* package, this script specifies the *docker* package in the **yum update** command. If the package name is omitted, all the available updates are applied. The prior configuration file example demonstrates this. ``` ### update_package.sh ### #!/bin/bash /opt/elasticbeanstalk/bin/pkg-repo unlock yum update docker -y /opt/elasticbeanstalk/bin/pkg-repo lock yum clean all -y rm -rf /var/cache/yum ``` ## download-source-bundle (Amazon Linux AMI only) On Amazon Linux AMI platform branches (preceding Amazon Linux 2), Elastic Beanstalk provides an additional tool, which is `download-source-bundle`. Use this tool to download your application source code when deploying your platform. The tool is available at `/opt/elasticbeanstalk/bin/download-source-bundle`. The example script `00-unzip.sh` is located in the `appdeploy/pre` folder on environment instances. It demonstrates how to use `download-source-bundle` to download the application source code to the `/opt/elasticbeanstalk/deploy/appsource` folder during deployment.