Skip to content

Latest commit

 

History

History
202 lines (123 loc) · 8.4 KB

sdlc-basics.adoc

File metadata and controls

202 lines (123 loc) · 8.4 KB

SDLC Basics

Pushing to Cloud Foundry

Pushing via CLI

Use cf help and/or cf <command> --help for details on each of the commands below.

  1. Review the docs: http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/deploy-app.html

  2. Verify you are logged in and targeted to your PCF instance:

$ cf target -s production
  1. Make sure you’re targeting your production space!!!

  2. Push the cities-service (here is the link to the jar incase you missed it).

    1. Be sure to name your application '<first-initial><last-initial>-cities-service'

    $ cf push <your_app> -i 1 -m 512M -p cities-service.jar

Your app should have crashed because it can’t find a database. So now we need to bind a service to your application to provide the database.

Binding a production database to your production app

  1. Review the docs on Services:

  2. Create a mysql service instance from the market place. We will consider the mysql farm deployed with PCF to be production for our class.

  3. Launch the DB console via the Manage link in the Users Console. Note the database is empty.

Manually Binding the Service Instance

  1. Review the docs on Binding a Service Instance

  2. Bind the instance to your app

  3. Restage your application to inject the new database.

Binding a database to your test instance.

  1. Target your development space.

    $ cf target -s development
  2. Repeat all the steps from the section above to push and bind a service for your development instance of cities-service. Make sure you append -dev to the route associated with your app. Cloud Foundry will not let you deploy and use the same route as another application unless you explicitly tell it to.

    1. hint cf push --no-start can make the push bind restage process a bit less cumbersome.

  3. Did it work? Why not?

    1. Think back to what Josh said in the operations section about what I provisioned for you. Basically, there’s a firewall that’s preventing you from connecting to the production database.

    2. This is a good time to read about Application Security Groups.

    3. You can see what security groups are applied to your space with the command: cf security-groups

    4. You should try to change it, just to prove to yourself that you can’t. Only admin can change, create or apply security groups. Take a look at cf create-security-group.

Environment Variables

It looks like we need to modify our security group to allow egress. But how do you know what endpoint is needed?

  1. Review the document on Environment Variables: http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/environment-variable.html

  2. Take a peek at Production, we’ll connect to the same database farm for development, so the IP there suits our needs.

  3. QUESTION: What variable shows your mysql service instance?

  4. At this point, holler at Josh and I’ll change the security group.

    1. You can now bind your service, but you’re not seeing data from the production instance, you have you’re own separate copy.

    2. Provisioned instances can only be shared inside of a space.

  5. Now, restart and verify you can access your application in the development space via a curl request:

    $ curl -i <your-app>-dev/cities

Using Manifests

Now, use a manifest to help automate deployment.

  1. switch back to your production space

  2. Review the documentation: http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/manifest.html

  3. Create an application manifest called manifest.yml in the same directory as your jar file. Minimally, you must set the name of the app, the amount of memory, the number of instances, and the path to the .jar file.

    Be sure to name your application '<first-initial><last-initial>-cities-service' and use this as the host value.

Binding via the Manifest

  1. Add the services binding to your deployment manifest and repush the app by running cf push with no parameters.

  2. Verify you can access your application via a curl request:

    $ curl -i <your-app>/cities
  3. In the developer console, navigate to the manage tab for the database associated with your application and checkout the available information.

Scaling

Apps can be scaled via the CLI or the Console.

Vertical Scale

  1. Increase your app memory to 1G.

  2. QUESTION: What happens? How long does it take? Why?

  3. Scale your app memory back down to 512M.

Horizontal Scale

  1. Scale your app to 2 instances.

  2. QUESTION: What happens? How long does it take? Why?

  3. Attempt to Scale your app to 20 instances

  4. QUESTION: What happens? Why?

    1. Quota? How do you get more?

  5. QUESTION: What if you run the environment out of space, who can increase DEA capacity.

    1. Check with Instructors for any recommended PCF Foundation Scale operations, time permitting we can do this in class.

Additional References

Application technology references for how the cities app is built:

User Provided Service Instances & Tags

The s3 bucket also includes a cities-ui.jar. This is an application which uses the cities-client to consume from the cities-service.

The cities-client demonstrates using the Spring Cloud Connector project to consume from a microservice. This is a common pattern for 3rd platform apps. Be sure you understand how it works.

The goal of this exercise is to use what you have learned to deploy the cities-ui application.

Deploying the Cities UI App

Creating a Service Instance & Deploy

  • You will need to connect the cities-ui application to a cities-service instance.

  • Make sure you are in your production space!

  • You can create a User Provided Service Instance and bind this to the ui application.

    • Review the documentation on User Provided Service Instances

    • Look for the details by running cf help.

    • Windows users, you are better off using the interactive variant of the command

  • You will need to specify two parameters when you create the service instance: uri and tag (see: CitiesWebServiceInfoCreator.java).

    • The uri should point to your deployed microservice

    • The tag is a property specified in the CitiesWebServiceInfoCreator. Tags have a special meaning in CF:

      Tags provide a flexible mechanism to expose a classification, attribute, or base technology of a service, enabling equivalent services to be swapped out without changes to dependent logic in applications, buildpacks, or other services. Eg. mysql, relational, redis, key-value, caching, messaging, amqp. Tags also allow application configurations to be independent of a service instance name.

      Refer to the CitiesWebServiceInfoCreator class for the necessary tag value.

  • Create the user provided service instance.

  • Deploy using the manifest.yml you downloaded earlier. Again make sure you prefix your initials.

  • Access the cities-ui to verify it is connected to your instance of cities-service.

  • QUESTION: Could we have used this technique to connect to an external datasource (like your Exadata)?