Step 2: Initialize App2Container - AWS App2Container

Step 2: Initialize App2Container

The containerization process consists of several distinct phases. This step focuses on the initialization phase, during which you initialize App2Container's global settings, and configure remote command settings if you are using a worker machine.

The init command performs one-time initialization tasks for App2Container. This interactive command prompts for the information required to set up the local App2Container environment. Run this command before you run any other App2Container commands. For more information, see the init command reference page.

If you are using a worker machine to run commands remotely on application servers, you must also run the remote configure command on the worker machine. For more information, see the remote configure command reference page.

Choose the tab that matches your operating system (OS) platform to continue:

Linux

On each server where you installed App2Container, run the init command as follows.

$ sudo app2container init

You are prompted to provide the following information. Choose <enter> to accept the default value.

  • Workspace directory path – A local directory where App2Container can store artifacts during the containerization process. The default is /root/app2container.

  • AWS profile – Contains information needed to run App2Container, such as your AWS access keys. For more information about AWS profiles, see Configure your AWS profile.

    Note

    If App2Container detects an instance profile for your server, the init command prompts if you want to use it. If you don't specify any value, App2Container uses your AWS default profile.

  • Amazon S3 bucket – You can optionally provide the name of an Amazon S3 bucket where you can extract artifacts using the extract command. The containerize command uses the extracted components to create the application container if the Amazon S3 bucket is configured. The default is no bucket.

  • You can optionally upload logs and command-generated artifacts automatically to App2Container support when an app2container command crashes or encounters internal errors.

  • Permission to collect usage metrics – You can optionally allow App2Container to collect information about the host operating system, application type, and the app2container commands that you run. The default is to allow the collection of metrics.

  • Whether to enforce signed images – You can optionally require that images are signed using Docker Content Trust (DCT). The default is no.

Windows

On each server where you installed App2Container, run the init command as follows.

PS> app2container init

You are prompted to provide the following information. Choose <enter> to accept the default value.

  • Workspace directory path – A local directory where App2Container can store artifacts during the containerization process. The default is C:\Users\Administrator\AppData\Local\app2container.

  • AWS profile – Contains information needed to run App2Container, such as your AWS access keys. For more information about AWS profiles, see Configure your AWS profile.

    Note

    If App2Container detects an instance profile for your server, the init command prompts if you want to use it. If you don't specify any value, App2Container uses your AWS default profile.

  • Amazon S3 bucket – You can optionally provide the name of an Amazon S3 bucket where you can extract artifacts using the extract command. The containerize command uses the extracted components to create the application container if the Amazon S3 bucket is configured. The default is no bucket.

  • You can optionally upload logs and command-generated artifacts automatically to App2Container support when an app2container command crashes or encounters internal errors.

  • Permission to collect usage metrics – You can optionally allow App2Container to collect information about the host operating system, application type, and the app2container commands that you run. The default is to allow the collection of metrics.

  • Whether to enforce signed images – You can optionally require that images are signed using Docker Content Trust (DCT). The default is no.