Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

NOTE 8-17-2015 

This currently only applies to using Moves with sais-common, and not with csf and beyond

Administering Moves

This page focuses on the Administration section of Moves. To see a description of the startup properties required look at Moves Property File settings.

The entities that need to be administered for moves are listed below.

  1. Moves Property File settings
  2. #Repositories
  3. #Environments
  4. #Stacks
  5. #Containers
  6. #Applications
  7. #RemovingArtifacts
  8. #BuildConfiguration
    1. #BuildConfiguration-Maven
    2. #BuildConfiguration-Subversion
    3. #BuildConfiguration-OC4j

Table of Contents

In general you should set entities up in the order that they appear above. The entities are described in detail below.

Anchor
Application Release Components
Application Release Components

Application Release Components

(aka "Why doesn't my new app show up in the list of apps on the "Build a Release" page?)

To get your new app to appear in the drop-down list on the "Build a Release" page, it needs to be added to a pom file in the "maven/releases" project in the sais-sis-common repo. The URL is:

svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/trunk/pom.xml

You will need to know:

  1. The app's maven group id
  2. The app's maven artifact id
  3. The URL for the app's trunk in the scm

You will add a "releaseComponent" section under the "releaseComponents" section, that will look like this:

Code Block
<releaseComponent implementation="edu.mit.maven.plugins.release.common.ReleaseComponent">
  <groupId>edu.mit.ist.es.supervasgn</groupId>
  <artifactId>assignsupervisor</artifactId>
  <scm>
    <developerConnection>scm:svn:svn+ssh://svn.mit.edu/sais-sis-academic/academic-supervasgn-web/trunk</developerConnection>
  </scm>
</releaseComponent>

Check this change in, and the app should now appear in the drop-down list in Moves.

Anchor
Repositories
Repositories

...

Repositories are maven repositories, accessible to moves over http/https. An example is the the SAIS Group repository at https://mv-ezproxy-com.ezproxyberklee.flo.org/nexus/content/groups/saisGroupRepoImage Removed. Maven has a well defined format, which specifies where to find an application within a repository. Each Application has an 'ArtifactId', a 'GroupId' and a 'Version'. So, for example, moves itself has artifactId=sais-moves-web, groupId=edu.mit.ist.es, versionId=2.0.0. Maven will translate this, by default into a final location of https://mv-ezproxy-com.ezproxyberklee.flo.org/nexus/content/groups/saisGroupRepo/edu/mit/ist/es/sais-moves-web/2.0.0/sais-moves-web-2.0.0.warImage Removed" The properties you need to configure for a repository are:

...

Property Name

Description

${groupId}

replaced with the groupId of the application being deployed

${artifactId}

replaced with the artifactId of the application being deployed

${version}

replaced with the version of the application being deployed<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f103b537-074b-4ec5-925a-96889158042c"><ac:plain-text-body><![CDATA[

${app.[paramName]}

replaced with the parameter value with key 'paramName' of the application being deployed

]]></ac:plain-text-body></ac:structured-macro>

The values for all parameters except 'version' are specified in the Administration -> Stacks -> Application section of moves. The version is selected during the deploy/build workflows by the user who has requested a deploy/build workflow.

Note that in In order to access the MIT repository, you must also have correctly configured SSL access and a Maven username and password that is authorized to view the repository you have configured. See the properties webservices.trustStore, webservices.trustStorePassword, mit.maven.repository.username and mit.maven.repository.password as described in the page Moves Property File settings for details.

Note that when you have configured an app that has at least one release in the MIT repository, you can test repository connectivity by going to Administration -> Stacks and clicking on the 'ping app' icon ( Image Removed) for your app. The resulting page will look like the following:
Image Removed

If your app and repository are configured correctly, versions that exist in Maven should appear on the resulting page. You should be able to click on the download icon ( Image Removed ) for any page and save the application binaries to your hard drive. (Tip: open jar, war or ear files using winzip or any other program that will allow you to verify that the downloaded application is valid.
If you cannot download an application using this test, you will NOT be able to deploy that application using Moves!!!

Anchor
Environments
Environments

...

Environments are really just a lookup that identifies the function of containers within a stack. The standard environments are 'Production', ' QA', and 'DevelopmentTest'. These are already should be automatically set up when Moves is deployed for the first time, so they will not need to be changed. However, we allow creation of new future environments (for example 'Continuous Integration' or 'Staging'). Note that the property file may need to be edited (and the moves application restarted). See the section 'Oracle Application Server usernames and passwords' in Moves Property File settings.

Anchor
Stacks
Stacks

Stacks

A Stack is simply a grouping of Applications and Containers by Environment. Stacks allow Moves to answer the question 'What is the container for Application 'X' in Environment 'Y'. Once you create a Stack, you can add containers to it for each environment. When we subsequently configure an application, we will tell it what Stack is associated with that application. (So, for example, the application 'OGS Application' might reference 'OGS Stack'. 'OGS Stack' references containers for 'Production', 'QA', and 'Development'). By looking at these relationships, Moves knows which container to deploy to when asked to deploy to a particular environment.

It is better to first configure and test containers before configuring apps. Further it is advisable to have developers release at least one version of an application to the Maven MIT repository. Doing so allows the admin to set up containers and applications for a stack.

Anchor
Containers
Containers

Containers

A container is the service that an application is deployed to. When you configure a new Container, you will be asked to select from one of the container types. The two container types that are currently available are

...

  1. Start off by making sure you have network access between the Moves Server and the Container you wish to deploy to. (For non-local deployments you will need the IS&T infrastructure team to complete these steps).
    1. open a shell on the machine where Moves is running.
    2. cd to the ORACLE_HOME folder for this machine (typically /home/oracle/product/10.1.3/j2ee/home)unmigrated-wiki-markup
    3. type *java -jar admin_client.jar \ [deployerUrl] \ [oc4j-admin-username] \ [oc4j-admin-password] -listApplications*. You should see a list of zero or more applications. *You MUST be able to execute this step without getting errors before even bothering returning to Moves!!!* The most common sources of error here are no network connection (firewall or ipconfig issues), bad usernames/passwords, incorrect deployer urls.
    4. Upon completion of this step, make a note of the deployerUrl, oc4j-admin-username and oc4j-admin-password.
  2. For the environment type that you will be using, verify that the oracle username and password found in the previous step are correctly set up in the properties file. See Moves Property File settings, specifically the section 'Oracle Application Server usernames and passwords'.
  3. On the Administration->Stacks->Container page, make sure the environment type is correctly set, and that the deployerUrl matches the previous step.
  4. Save the container, and .
  5. Anchor
    ServerTestPage
    ServerTestPage
    Use the Server Test Page! Simply click on the "container ping" icon for that container ( ) for the container you want to test. The page should list the same applications as were listed in the prior step. If you get errors with this page, go back and verify everything in the prior steps.the Server Test Page returns an error, go through the steps above again. You will NOT be able to deploy to a container that does not return a successful response on the Server Test Page!

Anchor
Applications
Applications

...

Applications represent web apps (.war or .ear applications) that can be deployed to a container. Before configuring an application, obtain the following information from the development team

  1. maven groupId
  2. maven artifactId
  3. application prefix (anything in the war/ear file name that precedes the artifact id)
  4. application suffix (anything in the war/ear file name that follows the 'artifactId'-'version')

You should also request that the development team release at least one version to the MIT Maven repository

You should also plan to have the following information

  1. application name (usually same as artifactId. This is what shows up in OC4J's admin console)
  2. application parent (usually 'default')

Application configuration is used to

  1. Find released applications in maven
  2. Deploy applications to a container

The following screen shot shows the parameters used for the Template Web Application.

Image Modified

Application Parameters explained.

The application parameters are used to

  1. find an application version in the MIT maven repository
  2. deploy an application to a container

Let's look at the parameters used to find an application in the MIT maven repository first. When we set up the baseUrl in the Repository configuration section, it was defined as something like /nexus/content/groups/saisGroupRepo/${app.groupId}/${app.artifactId}/${version}/${app.artifactId}-${version}${app.applicationSuffix}. Moves will dynamically replace anything that matches ${app.param name} with the value of the parameter that it finds in the application's configuration.

  1. applicationPrefix - Not used
  2. applicationSuffix - This is usually .war (for war files) or "*.ear" for ear files. Moves will replace {app.applicationSuffix} with this value when creating the actual repository url.
  3. artifactId - The artifactId from the maven pom.xml file for this application.
  4. groupId - The groupId from the maven pom.xml file for this application. any "."s in groupId are replaced with "/"s.

Thus, in our example above, version 1.2.3 of the application would be found in the repository url /nexus/content/groups/saisGroupRepo/edu/mit/ist/es/template/1.2.3/template-123.war

The parameters contextRoot, deploymentName and parent apply to OC4J deployments only. They do not affect how a release is found in maven.

h7. Debugging Application Parameters that relate to Maven.
anchorBuildConfigurationBuildConfiguration

...

:ApplicationTestPage}

Application parameters are complex, because we wish to maintain compatibility across different Maven repository layouts and different containers. Help is at hand, however.
Once you have configured an application, click on the Maven Repository Ping Tool ( Image Added ). See figure below.
If you have followed the instructions above, there should be at least one release in the MIT repository. In Administration -> Stacks click on the 'ping app' icon ( Image Added) for your app. The resulting page will look like the following:
Image Added

If your app and repository are configured correctly, versions that exist in Maven should appear on the resulting page. You should be able to click on the download icon ( Image Added ) for any page and save the application binaries to your hard drive. (Tip: open jar, war or ear files using winzip or any other program that will allow you to verify that the downloaded application is valid. Just 'cos a file gets saved is NOT A SUFFICIENT TEST

If you cannot download an application using this test, you will NOT be able to deploy that application using Moves!!!

Image Added

If you have set up maven correctly, AND if a build exists in Maven for the application you configured, then each version in Maven will show up like in the attached file. Click on the Download Icon ( Image Added ) for a version, and the component should be downloaded from the Maven repository. Make sure you open the downloaded file in a program that can read zip files (e.g. winzip). The resulting download should show a folder hierarchy with '.class' files, '.jsp' files etc If this doesn't work, then you should use the following debugging approach

  1. IF NO applications can be pinged, check that you can connect to Maven using a web browser. Use the version URL defined in the container ping page. If you get a 404
    1. Use the username and password defined in the Moves properties file (see Moves Property File settings).
    2. Use the hostname defined in the Administration -> Repository page.
  2. Check that you do not see java SSL exceptions in the log, or in the container ping page. (These can be cryptic to read). If you suspect SSL exceptions, make sure that the Moves Trust Store is properly configured (see Moves Property File settings).
  3. Check that the Repository Location urls do not give 404 errors when you click on them.

Once you have verified that a build exists in the MIT Maven repository for this application, then you MUST be able to download a version using the Download Icon ( Image Added ). If you can't download a version and open it in winzip (or other archive program), Moves will certainly not be able to deploy the application.

Anchor
BuildConfiguration
BuildConfiguration

Build Configuration

The Build Configuration allows you to configure certain aspects of Moves without restarting the server.

Anchor
BuildConfiguration-Maven
BuildConfiguration-Maven

Build Configuration - Maven

This page allows you to define

  1. Where maven is located on the system
  2. Whether to include verbose logging in builds (This should really be moved to the build workflow)
  3. Where build artifacts are stored
  4. How long a build should take before we kill it.
  5. Where the mit maven repository is located (This is duplicated in Admin ->Repositories because the setup for Moves and Maven is quite different)
  6. The maven goal for releasing an app. This is fully qualified, and contains the groupId, artifactId and version of the plugin. This allows us to "upgrade" the plugin when it has been adequately tested). An example is edu.mit.maven.plugins:mit-release-plugin:1.2.3:release. Usually only the version number will change (in this example the version is 1.2.3).
  7. The maven goal for populating build drop downs. This is fully qualified, and contains the groupId, artifactId and version of the plugin. This allows us to "upgrade" the plugin when it has been adequately tested). An example is edu.mit.maven.plugins:mit-release-plugin:1.2.3:info. Usually only the version number will change (in this example the version is 1.2.3).
  8. Wiki MarkupMaven System Properties. These are passed as -D\[propertName]=\[propertyValue] parameters to Maven. For MIT we need to provide correct values for the java system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword
  9. Maven System Properties. These are used to set up the shell environment that Maven runs in. Typically this means correctly setting MAVEN_OPTS, JAVA_HOME, M2_HOME, PATH, and the subversion environment variable SVN_SSH. SVN_SSH is used to tell subversion where the public key is to connect over SSH without prompting for a password.
    javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword

...

Anchor
BuildConfiguration-Subversion
BuildConfiguration-Subversion

Build Configuration - Subversion

In the subversion config page, we just need to tell moves

...

Anchor
BuildConfiguration-OC4j
BuildConfiguration-OC4j

Build Configuration - OC4J

The OC4J Home folder tells us where to find admin_client.jar.

...