Cloud Foundry Blog

About Nieraj Singh


Cloud Foundry Eclipse 1.6.0: Spring Boot Support and Self-Signed Certificates

Cloud Foundry Eclipse integrates Cloud Foundry server and application management into Eclipse and Spring Tool Suite (STS). You can push applications to a Cloud Foundry server via drag and drop from the Eclipse Project Explorer much in the same way as deploying to a local tomcat server. Application memory and instances can be scaled easily, and services created and bound to an application through drag and drop. A comprehensive description of the plug-in is available at:

http://docs.cloudfoundry.org/devguide/deploy-apps/sts.html

Since 1.5.0, we have been busy making CF Eclipse ready to better support new features in Cloud Foundry public and private servers.

Version 1.6.0 introduces additional enhancements:

  1. Support for Spring Boot applications.
  2. Creating server instances to private clouds that use self-signed certificates.
  3. Environment variables for applications.
  4. Open memory configuration for applications.
  5. Comprehensive console output.

In this article we will cover these new features through an example where a Spring Boot application is deployed to a private Cloud Foundry server.

Installation

Spring Tool Suite 3.4.0 or higher integrates with Spring Boot. This allows you to create various types of Spring Boot projects like web, batch, and AMQP. Further reading can be found at:

http://docs.spring.io/sts/nan/v340/NewAndNoteworthy.html

In order to use the Spring Boot integration for STS, install Cloud Foundry Eclipse 1.6.0 into STS 3.4.0 or higher following these instructions:

http://docs.cloudfoundry.org/devguide/deploy-apps/sts.html#install-to-eclipse

Creating a Cloud Foundry Server Instance

Once Cloud Foundry Eclipse 1.6.0 has been installed, open the Servers view in STS/Eclipse, and create a new server instance. This can be done by right-clicking on the view to open the context menu and selecting:

New -> Server

server_newserver

In the first page, select “Cloud Foundry” under “Pivotal”, and click “Next” to open “Cloud Foundry Account”. Click on “Manage Cloud…” to add the URL to the private cloud.

server_wizard

Click “Add” and enter a name and URL for the private cloud.

server_manage_cloud_URLs

server_private_cloud_URL

After clicking “Finish”, a warning may appear indicating that the URL failed to validate. Click “Yes” to keep the URL. This will return to the “Manage Cloud URLs” dialogue.

server_unable_to_authenticate_URL

Click “OK” in the “Manage Cloud URLs” dialogue to return to the credentials page. Enter a username and password and click “Finish”, which will validate the credentials as well as automatically select the first organization and space that it finds as the server’s target space. Alternately, click “Next” to select another organization and space.

While validating the credentials, by clicking on “Finish”, “Next” or “Validate Account”, a confirmation dialogue is displayed showing that the server uses self-signed certificates, and whether to proceed in creating the server instance. If you select “Yes”, the Cloud Foundry Eclipse plug-in will remember the decision for any future server instance creation to this URL, and you will not be prompted again.

self-signed-cert

Once the server instance is successfully created, it will appear in the Servers view.

Creating and Configuring Spring Boot App

Now we create a Spring Boot application. Right-click on the Project Explorer and select:

New -> Spring Starter Project

This opens the Spring Boot (Starter) Project creation wizard. Enter details and the Spring Boot application type, and click “Finish”.

create_spring_boot_app_1

create_spring_boot_app_2

Once the project is created and built in the STS workspace, right-click on it and select:

Configure -> Enable as Cloud Foundry App

configure_spring_boot_CF

This step is necessary and allows the project to be deployable to a Cloud Foundry server instance in STS.

NOTE: As of version 1.6.0, this configuration only applies to Java Spring Boot applications, that is, Spring Boot applications that are packaged and deployed as jar files.

Pushing the Spring Boot Application

Once configured, you can simply drag and drop the Spring Boot project onto the private cloud in the Servers view.

This opens the Application Deployment wizard. You can click “Finish” right away, or “Next” to further configure the application. For instance, you can modify the mapped application URL, memory (default is set to 512MB), bind services, or set environment variables.

spring_boot_wizard_1

For our case, we click “Next”, and modify the memory.

spring_boot_wizard_2

Version 1.6.0 now supports open, variable memory configuration. Whereas previous versions of the plug-in restricted the memory choices, you can now enter any MB value over 0 up to your maximum allowed allocation. We change the default 512MB to 437MB.

spring_boot_wizard_2memorychange

Clicking “Next” will allow you to bind services, and a further click on “Next” opens the Environment Variables page, which is another new feature in version 1.6.0.

spring_boot_wizard_env_1

To add a new environment variable, right-click on the table to open the context menu and select “Add”. In our example we enter a RECAPTCHA_PRIVATE_KEY environment variable.

spring_boot_wizard_env_2

spring_boot_wizard_env_3

Click “Finish” to push the application to the Cloud Foundry server.

Application Staging and Console Output

Once the application begins deployment, the Eclipse console will automatically open and show progress during different stages of the deployment.

Version 1.6.0 introduces more comprehensive console progress than previous versions of the plug-in, displaying completed stages of the application deployment and start process.

console_staging

After the Spring Boot application completes staging and has successfully started, the console will display the application’s standard out and error logs.

console_staging_2

While the application is running, at any time you can refresh the console output by right-clicking on the application in the Servers view and selecting “Show Console”. This will only show the application’s standard out and error log files.

show_console

show_console_2

Editing Environment Variables and Memory

To edit application environment variables and memory, double-click on the application in the Servers view. This will open the Cloud Foundry server editor, and display bound services and instance stats for the application. The “General (Application Restart Required)” section allows environment variables and memory to be adjusted. For these changes to take effect, the application has to be restarted, which can be done directly from the Cloud Foundry server editor by clicking on either “Restart” or “Update and Restart”.

cf_editor

Improved Application Deployment

With version 1.6.0, we have enhanced application deployment from Eclipse-based IDEs. Pushing applications to private servers that use self-signed certificates is now possible. Furthermore you can now easily push Spring Boot projects to Cloud Foundry servers via drag and drop, much like any other web project.

We continue to further enhance the Cloud Foundry experience in Eclipse and STS in each new release of the plug-in.

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Cloud Foundry Integration for Eclipse Can Now Launch External Command-line Applications Using Service Tunnels

In the course of developing, testing and deploying cloud applications, developers sometimes need to directly access the application data. The Cloud Foundry Integration for Eclipse advances this capability and now features the ability to launch external command-line applications for Cloud Foundry services like MySQL and PostgreSQL. The plugin offers Spring and Java developers using Eclipse or STS a way to manipulate, or port the data contained in their Cloud Foundry applications more easily.

An earlier release of the Cloud Foundry plugin (1.1.0) introduced tunneling support for data services, and the command-line application feature in 1.4.0 now extends the support by automatically resolving tunnel values when launching a command-line application for a Cloud Foundry service. In addition, a set of predefined commands for executing commonly used command-line applications are available by default, and ready to use if the external command-line application is installed and set in the operating system’s PATH environment variable.

These commands are launched from within Eclipse or STS, and executed in an external command-line terminal. New commands can be defined either through a new Eclipse preference page for Cloud Foundry, or by opening a Service Tunnel Commands wizard from the Services table in the Cloud Foundry Server editor. The commands are stored as Eclipse preferences and therefore persisted across Eclipse runtime sessions.

In this blog, we will describe the steps to define and launch a new mysqldump command that automatically generates a dump file for a Cloud Foundry MySQL service. This blog assumes the reader has basic understanding of how to create a Cloud Foundry server in Eclipse, as well as create services through the Cloud Foundry Server editor’s Applications tab.

The command-line application feature in 1.4.0 allows users to launch an external application by simply selecting a service in the Services table in the Cloud Foundry Server editor and right-clicking to execute a particular command from the Services table context menu (see Figure below). The launch process then automatically creates a tunnel if one was not already created and executes the command in the operating system’s default terminal application. Terminal applications can also be changed per command definition. For example, in Linux the default terminal used by the feature is xterm, yet a user can change a command to use a different terminal like gnome-terminal.

Predefined Commands

The Cloud Foundry Integration for Eclipse version 1.4.0 provides a list of predefined commands that are ready to use for MySQL, PostgreSQL, MongoDB, and Redis services, provided the corresponding applications are installed. The commands are accessible by right-clicking on a service in the Services table in the Cloud Foundry Server editor:

cf140_base_context_menus

The list of commands are:

MySQL:

  1. mysql
  2. mysqldump

MongoDB:

  1. mongo
  2. mongodump
  3. mongorestore

PostgreSQL:

  1. psql

Redis:

  1. redis-cli

If these applications are already set in the operating system’s PATH environment variable, these commands can be executed right away without changes, and are launched in an external terminal like Terminal.app for Mac OS X, cmd.exe for Windows, and xterm for Linux.

For example, launching mysql for a MySQL service in the Cloud Foundry editor will automatically connect the mysql application to the MySQL service in the Cloud Foundry server through a tunnel, provided mysql is installed and set in the OS PATH environment variable. The end result is an external terminal window opening outside of Eclipse, displaying the mysql application prompt:

cf140_external_terminal_mysql

Since the tunnel credentials are resolved automatically for the external application by the Cloud Foundry plugin, the mysql application automatically connects to the data service and opens the mysql prompt without asking the user for credentials.

If new commands need to be added, or existing ones edited, they can be done so by either selecting Command Definitions in the Services table context menu, or by opening Eclipse Preferences -> Cloud Foundry -> Service Tunnel External Application Commands

Creating a New mysqldump Command

In our example, we will be adding a new mysqldump command that creates a particular output dump file called myoutputfile.txt. Although a mysqldump command already exists by default as part of the set of predefined commands, we will create a separate one where a dump file is explicitly set.

Commands are associated per service vendor, so the new mysqldump command will apply to any MySQL service regardless of the Cloud Foundry server.

To add a new command, choose Command Definitions from the Services table context menu to open the Service Tunnel Commands wizard, select the desired service, and click “Add”.

cf140_service_tunnel_commands_wizard

This will open the Command Definition wizard:

cf140_pt1_add_command

Two required properties are needed to define a command:

  1. A unique display name. Two or more commands with the same name cannot exist for a given service.
  2. An executable location, or just the name of the application if already set in the OS PATH environment variable.

Optionally, a user can also define command options that are passed to the application when it is being executed, and environment variables that are set by the Cloud Foundry plugin prior to launching the command. Option variables using the pattern ${variablename} can be used in the options definition.

These variables are grouped into two types:

  1. Tunnel-specific variables that are reserved for tunnel values like username, password, port, and database name. These variables are automatically resolved by the Cloud Foundry plugin when the command is launched.
  2. Additional variables that will be prompted to the user in a dialogue when the command is executed.

Some applications like psql require that passwords be set as environment variables. As with command options, variables using the pattern ${variablename} can be used in place of environment variable values.

cf140_add_env_variables

In addition, the terminal definition can also be adjusted for that particular command, and optionally applied to all current and future commands by editing the terminal launch command value in the External Command Line Terminal section.

To facilitate creating custom commands, the list of predefined commands are available via a drop-down control, and can be used as templates for new definitions:

cf140_pt1b_predefined_mysql

Let’s select mysqldump from the list. It will now populate the wizard with the default definition for myslqdump, including the necessary options required to run the application. Since we already have a default mysqldump command, an error will appear asking the user to set a different display name:

cf140_pt2_name_already_exists

Now, we want to edit the display name and give it a unique name, and also set a specific name for the dump file: myoutputfile.txt. In addition, we are changing the location of the mysql executable as we do not have it set in the OS PATH environment variable.

cf140_pt3_edited_command_definition

Clicking “Finish” in the Command Definition wizard will now add the command to the list of commands for the MySQL service:

cf140_pt4_commands_wizard_with_changed_name

Clicking “Finish” once more in the Service Tunnel Commands wizard will persist the changes. At this point, clicking “Cancel” will alternately cancel any changes made to any services.

Now let’s right-click on the MySQL service in the Services table, and we’ll see the newly added mysqldump with outputfile command in the context menu. Selecting this command will execute it, and if necessary, automatically create a tunnel connection if one wasn’t already present.

cf140_pt5_context_menu_new_command

After the command executes, the following dump file is created in the user’s home directory:

cf140_pt6_mysql_dump

If instead of executing the custom mysqldump with outputfile that was created above, a user runs the default mysqldump command where the dump file is defined using an ${output file} variable, a dialogue will open prompting the user for the name of the output file prior to executing the command. The file name can include an absolute path, or if just specifying a name, it will be created relative to the user’s home directory.

cf140_pt7_prompt_outputfile

Variations in Terminal Launch

The command-line feature for 1.4.0 is supported in Mac OS X, Linux and Windows. However, there are differences in how a command is launched in an external terminal. For Mac OS X, the default terminal is Terminal.app, and the Cloud Foundry plugin executes the command and sets any environment variables in a temporary .sh script file that it creates and then passes as an argument to Terminal.app. This temporary file is deleted after the process running the command is launched.

For Windows and Linux, no temporary script file is created, and instead the command and its options are passed directly to the external process as process arguments.

Installing Cloud Foundry Integration for Eclipse 1.4.0

To install version 1.4.0, follow the documented instructions to install Cloud Foundry Integration for Eclipse. Earlier versions of the integration, starting from 1.0.0 can be updated from within Eclipse or STS. Note that updates for older Cloud Foundry plugins prior to 1.0.0 are not supported, and must first be uninstalled before installing 1.4.0.

Only Eclipse JEE Indigo and Juno, as well as STS 2.9.0 and GGTS 3.0.0 and higher are supported.

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Cloud Foundry Integration for Eclipse Now Supports Standalone Java Applications and Java 7

A new release of Cloud Foundry Integration for Eclipse is available which features the ability to publish standalone Java applications to CloudFoundry.com using either Java 6 or Java 7. Java 7 is also now supported for Grails, Java Web and Spring applications. Standalone applications can only be published to Cloud Foundry instances that support standalone applications such as CloudFoundry.com.

The new integration (version 1.2.0)  allows users to publish standalone Java applications from within Eclipse Indigo JEE or SpringSource Tool Suite (STS) version 2.9.0 or higher.

The previous Cloud Foundry plugin (1.1.0) introduced tunneling support for data services, and further improvements to service tunneling are also available as part of 1.2.0.

Follow the documented instructions to install the Cloud Foundry Integration for Eclipse. If you had previously installed Cloud Foundry plugin 1.0.0 or 1.1.0 in Eclipse or STS, the update will be automatically detected or you can manually check for updates in the IDE. Note that updates for older Cloud Foundry plugins prior to 1.0.0 are not supported. Old versions prior to 1.0.0 must first be uninstalled before installing 1.2.0.

Enabling Standalone Support

Java projects in Eclipse can now be published to CloudFoundry.com by enabling Cloud Foundry standalone support on the Java project, and then dragging and dropping them like any other supported application type (Grails, Spring) into either a Cloud Foundry server instance in the Servers view or into the Applications section in the server editor.

To make your Java project publishable to CloudFoundry.com, simply select it in either the Project or Package Explorer, right-click and choose Configure -> Enable as Cloud Foundry Standalone App.

To remove the configuration, select  Configure -> Disable as Cloud Foundry Standalone App.

A Java standalone application can be published in just a few simple steps:

  1. Right-click on the Java project and enable standalone support.

  2. Drag and drop the application into either the Servers view or server editor for a CloudFoundry.com server.

  3. Complete the Application wizard that opens, much like publishing any other supported application type.

Configuring a Standalone Java Application

Once a standalone Java application is dragged and dropped into either a CloudFoundry.com server instance in the Servers view, or the server’s editor, an Application wizard is opened allowing a user to configure the application details like the application name and runtime type.

Both Java 6 and Java 7 are supported for standalone applications and a user can select either one from the “Runtime” widget shown above.

In many cases, the standalone support will automatically detect a Java type with a main method, and the application can be deployed from the first page of the wizard. If no main method type was detected, or if a user wants to change the automatically resolved type, clicking “Next” will display a page where the Java start command can be set.

Unlike other supported applications like Grails or Spring, URLs are optional for standalone Java applications. However, a start command is required.

A user has the option of specifying the start command in one of two ways:

  1. Java: A JVM Java start command with recommended default options set to “$JAVA_OPTS -cp lib/*:.” and a Java type with a main method. The lib folder for the class path option need not exist in the Java project. It is automatically created remotely in the Cloud Foundry server and it is where all jar project dependencies, excluding the JRE dependency, are published.

  2. Other: A full user-defined start command, which may include the name of a script file.

For the first option, a user can use the built in Java content assist in the Main Type text widget to select a Java type.

Alternately, the Browse button can be clicked to open a Java type browse dialogue.

If selecting Other, the full start command can be specified, like a script file as seen below.

Once published, the standalone application can be managed from the Cloud Foundry server editor like other application type, including starting, stopping, restarting and update restarting, and removing the application, as well as changing the number of application instances and memory settings. In addition, the published resources can be browsed by clicking on Remote Systems View in the server editor.

Java Application Dependencies

All standalone dependencies, with the exception of the JRE dependency, are automatically resolved and published to a remote “lib” folder relatively to the application folder in the Cloud Foundry server. The lib folder need not exist in the Java application before publishing it.

For example, for a Java Maven project, all Maven dependencies are published to the remote lib directory relative to the application.

The Cloud Foundry standalone support determines what application resources to publish to the cloud server based on the configuration defined in the project’s Java Build Path. Any resources that the application requires, including Java source output or target folders, binaries, and XML and script files, need to be listed in the project’s Java Build Path. The Java Build Path can be accessed by right-clicking on the Java project and selecting Build Path -> Configure Build Path…

In addition, the standalone support automatically skips any test source folders, even when listed in the project’s Java Build Path. Output targets for sources folders containing the pattern “src/test” are skipped.

Java 7 Support for Other Application Types

In addition to supporting Java 7 for standalone applications, Cloud Foundry Integration for Eclipse and STS now supports Java 7 for Grails, Spring, Java Web and Lift for CloudFoundry.com. For other cloud servers, Java 6 is still the default runtime type. Java 7 is only shown if the server supports it.

Cloud Foundry Integration for Eclipse 1.2.0 can be installed or updated from the official update site:

http://dist.springsource.com/release/TOOLS/cloudfoundry/

  • The Cloud Foundry Team

Don’t have a Cloud Foundry account yet? Signup for free today

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email

Cloud Foundry Integration for Eclipse Now Supports Tunneling to Services

Today we announce a new release of Cloud Foundry Integration for Eclipse which features the ability to open a tunnel to any Cloud Foundry data service. Now Eclipse users can use familiar client applications to directly analyze, manipulate, or port the data contained in their Cloud Foundry applications.

The Cloud Foundry Data Tunneling service can be created from the Services table in the Cloud Foundry Eclipse server editor. The new integration (version 1.1.0)  allows users to create data tunneling (also known as ‘Caldecott‘) from within Eclipse Indigo JEE or SpringSource Tool Suite (STS) version 2.9.0 or higher.

Follow the documented instructions to install the Cloud Foundry Integration for Eclipse. If you had previously installed the Cloud Foundry plugin in Eclipse or STS, the update will be automatically detected or you can manually check for updates in the IDE.

Creating a Tunnel

You can create a tunnel to connect to any running service in your Cloud Foundry account. Go to the Applications tab in the Cloud Foundry Server view. There is a listing of existing services under the Services section. Creating a tunnel is performed by simply right-clicking on a service in the table and selecting “Open Caldecott Tunnel” menu action:

This will automatically publish a tunneling application to your account, if one isn’t already published, and start or restart the application as necessary. This tunneling application will appear in the list of published applications as Caldecott. Cloud Foundry will also automatically bind the selected service to the Caldecott application prior to opening a tunnel.

The process of creating a tunnel requires services to be bound to the tunneling application. Cloud Foundry will automatically stop a running Caldecott application, bind the service, and restart the application to create the tunnel. Therefore, existing tunnels may be closed when a new tunnel is created, if the desired service was not previously bound to the tunneling application. Multiple tunnels can be opened to different services in your account at the same time, as long as all the related services are already bound to the Caldecott application prior to creating the data tunnels.

In general, any operation that requires the tunneling application to be stopped, restarted or removed will result in all existing  tunnels being disconnected. Manually unbinding a service from the Caldecott application through the Services table will also result in the associated tunnel being disconnected.

Once a tunnel is successfully created, a dialogue will open displaying the data service tunnel information necessary to use a tool like the Eclipse Data Source Explorer to connect to a data service in a Cloud Foundry server. The information displayed includes a username, password, and local port number:

As URLs are needed for database connections in tools like the Eclipse Data Source Explorer, they are automatically constructed for certain data services like MySQL and PostgreSQL. That way, users do not need to manually construct them when creating a database connection.

Right-clicking on the tunnel entry in the tunnel dialogue will display several context menu actions to copy field values to the clipboard. The menu action to copy the URL appears if the service is of MySQL or PostgreSQL type:

Managing Tunnels

Once a tunnel is opened, it can be managed from the Services table in the Cloud Foundry server editor. A sortable “Tunnel” column indicates which services have an open tunnel:

Right-clicking on a service allows users to either disconnect the tunnel or show the tunnel information.

Data tunnels can also be managed in the Servers view by right-clicking on a server instance and options will be presented to manage individual tunnels via wizard flow or disconnecting all existing tunnels:

These Servers view context menu actions are only displayed if the server has at least one active tunnel.

Creating Database Connections

Using the service tunnel information, database connections can then be created with the Eclipse Data Source Explorer, which is available by default in STS and Eclipse Indigo JEE installations:

Once a database connection is established, the database can be accessed through the Data Source Explorer:

To disconnect the tunnel, all data service connections must be disconnected. Therefore, active data service connections created by tools, such as the Data Source Explorer, must be terminated prior to disconnecting the tunnel from the Services table.

Cloud Foundry Integration for Eclipse 1.1.0 can be installed or updated from the official update site:

http://dist.springsource.com/release/TOOLS/cloudfoundry/

  • The Cloud Foundry Team

Don’t have a Cloud Foundry account yet? Signup for free today

Facebook Twitter Linkedin Digg Delicious Reddit Stumbleupon Email