Artifacts (application artifacts) refer to packages, images, binaries, file, scripts, and application data included in physical images that are stored in one or more repositories.
Typically, enterprises maintain application packages, data, and scripts in multiple repositories of their choice. Use the Artifact Repository to attach your own external repository to store and access your files. Workload Manager provides a Repositories tab in the Workload Manager UI for this purpose. The following screenshot shows the Repositories tab.
Workload Manager users can define their own repositories and store the required application binaries, scripts, and shared files. At deployment time, you can download (or upload for supported write operations) the required file from this repository.
You can provide the required repository credentials to authenticate supported repositories using secure access (Private key, Client Certificate, and Trusted Certificate).
Use the Artifact Repository to:
Point to application binaries, scripts, and shared files.
View and maintain the list of external repositories and point to the repository name in application profiles by providing a relative path.
Enterprises may decide to make the artifact repository (or multiple artifact repositories) specific to a user, a tenant, a cloud, or any combination of these resources based on their respective deployment requirement.
Using the Artifact Repository in an Application Profile
Tenant and users can view repositories specific to their tenant (or as permitted by their admin). Admins can enforce access permissions for each repository. See Permission Control for additional details.
Automatic Endpoint URL Detection
When modeling the application or application profiles, users can select the relevant repository to provide the relative path to the application packages/scripts/file path. The list of added/available repositories is displayed for user selection. When you select a repository, the endpoint URL is automatically appended and you only need to provide the name of the folder where the packages/scripts/files are located.
Workload Manager Repository Types
For each repository type, the Workload Manager platform provides additional fields to identify the configuration specific to each type.
The following table lists the supported repository types and the inputs required when configuring them in Workload Manager.
Use your own HTTP repository for application artifacts.
Provide the Hostname, Port, and optionally, Username/Password of your HTTP repository.
You can create HTTP repositories using Apache, Nginx or any other web server of your choice. You can then use HTTP repositories to host application artifacts.
Use your own HTTPS repository for application artifacts.
Provide the Hostname and Port. You can choose to provide the username/password or SSL credentials that comprise of the Private Key, Client/Trusted certificates of your HTTPS repository.
Use your own FTP repository for application artifacts.
Provide the Hostname, Port, Username/Password of your FTP repository.
Workload Manager only supports PASSIVE mode when using FTP repositories.
|Amazon S3 Repositories||Provide the Region, Access Key, Access Secret for your AWS account, and the name of the S3 Bucket, that you would like to use as your repository.|
Provide the Hostname, Port, Username/Password or the SSL Credentials of your Artifactory repository.
See repository documentation to set up your Artifact repository.
The central server that manages Puppet Agent(s). Refer to http://docs.puppetlabs.com (install Puppet) for additional context. Only displayed if you use the Puppet service.
Provide the Hostname (of the Puppet Master) and the Certname Suffix (authentication credentials for the Puppet Master). See Application Using Puppet or Chef for additional details.
The central server that manages the Chef clients. Refer to https://docs.chef.io/ (install server) for additional context. Alternately, you can also use the free Chef server image provided in the AWS Marketplace. Only displayed if you use the Chef service.
Provide the Hostname, Chef User Key, Chef Validation key and optionally Trusted Certificate of the Chef Server. See Application Using Puppet or Chef for additional details.
You can download the Starter Kit from the Chef console to obtain the validation key that must be specified in CloudCenter UI.
If your Chef Server is configured with a Public DNS, add the Public DNS in the Hostname field and copy the public DNS to the Trusted Certificate field when creating or editing the repository.
|Other Input||Provide the entire URL for the repository – this is the only option that is directly configurable for Workload Manager resources.|
To define a shared repository, you must first create the repository and then share the repository with applicable users or groups
Create a Repository
To create a repository, follow this procedure:
Access the Repositories tab in the Workload Manager UI.
Review the repositories (if any):
If the required repository is listed in this page, click the Edit icon. You can only edit a repository if you are the owner.
If the required repository is not listed, follow the rest of the procedure to add a new repository.
Click the Add Repositories button to add a new repository.
Provide the Basic Information required to model this repository.
Provide the authentication credentials, depending on your authentication scheme, provide username/password or certificate details for SSL.
Click Save. The newly added repository is saved and visible in the Your Repositories page.
Share the Repository
Each tenant and users within a tenant can only view shared repositories specific to their tenant (or as permitted by their admin).
To share a repository, follow this procedure:
Access the the Workload Manager UI and click Repositories.
For the required repository, click the Share Repository icon.
Associate the required Users, Groups, and Tenants who are permitted to access this repository and identify the Permission Control for each association. You can also choose to share this repository with all users and/or tenants.
Click Save. The newly added repository is saved and visible in the Repositories page.
Back Up and Restore Data for Application Migration
Some repositories also support Write operations can be used to backup (or restore) data to/from the repository as identified in the table above (see the Write Operations column).
To use this capability, you must provide the backup location (repository endpoint) for the backup/restore operation. Once you provide the relative path for the Backup Script, Backup Location, and/or the Restore Script, in the Migration Properties tab, these will be used to perform application migration between clouds.
|Backup Location||Application data is backed up to the repository specified in the Backup Location.|
Executed as root user.
Backup file syntax:
backupFile <file name and backup path on Backup location> <file with path to be backed up>
Use the backup shell script to call the util function. Include the following line to backup a file:
Executed as root user.
Restore file syntax:
restoreFile <file name>
By default, the file is restored to /opt/remoteFiles/.
Use the restore shell script to call the util function. Include the following line to restore a file:
- No labels