Getting started with IBM Bluemix
This chapter describes the following considerations for getting started with IBM Bluemix:
Understanding what you can build in IBM Bluemix
Creating and managing a Bluemix application
Bluemix users, spaces, and organizations
2.1 What you should be able to do
At the end of this unit, you should be able to:
Describe IBM Bluemix infrastructure types
Describe what you can build in Bluemix
Describe how to create an application in Bluemix
Describe the Bluemix dashboard, catalog, and documentation features
Describe how the application route is used to test an application from the browser
Describe how to create services in Bluemix
Describe how to bind services to an application in Bluemix
Describe the environmental variables that are used with Bluemix services
Describe Bluemix organizations, domains, spaces, and users
2.2 References
The following publications are useful for further research on the topic presented in this unit:
The Bluemix documentation from the web interface provides an up-to-date reference and tutorial on building, deploying, and managing applications.
Bluemix overview
Join the Bluemix developers community to view videos, tutorials, and forums.
Browse through a list of Bluemix solutions and sample applications.
2.3 Getting started: Create an IBM Bluemix account
Figure 2-1 Getting started: Create an IBM Bluemix account
Notes:
Before you work on any of the exercises in this course, you must sign up for an IBM Bluemix account. You do not need to specify a method of payment to create an account. You can register for a free IBM Bluemix trial account at bluemix.net.
2.4 IBM Bluemix infrastructure types
Figure 2-2 IBM Bluemix infrastructure types
Notes:
IBM Bluemix supports three alternative infrastructure types:
Cloud Foundry provides the PaaS environment to run your applications. IBM Bluemix manages and maintains the infrastructure that runs the applications.
With Cloud Foundry Apps, Bluemix allows basic management capability of your app and allows it to connect with prepackaged services. Cloud Foundry boilerplates and starter apps are the simplest way to get started with Bluemix.
IBM Containers provide more fine-grained control over the computing infrastructure to run the application and services through Docker-like APIs. You can use and extend public images from the IBM Bluemix catalog or images from the public Docker hub.
If you want to port an image from another cloud infrastructure provider, or if you want to use an existing public image, consider the IBM Containers technology. Containers give you a bit more control, but still do not require you to manage an operating system or network. IBM Containers resemble the popular open source container engine Docker, but have some Bluemix-specific features such as their ability to integrate with the Cloud Foundry routers.
Virtual Servers are software implementation of hardware that runs applications like a computer. You can configure the operating system, server runtime environment, and application.
If you want to have control over the infrastructure down to the operating system level, consider Virtual Servers.
Most developers in the enterprise will probably use some mix of the three types. The exercises in this course introduce you to the Cloud Foundry infrastructure in IBM Bluemix. As such, Containers and Virtual Servers are out of scope of this course. The focus will be on Cloud Foundry Apps for the remainder of this course.
2.5 What can you build in IBM Bluemix?
Figure 2-3 What can you build in IBM Bluemix?
Notes:
In Bluemix you can build applications, which are the programs that developers build in the Cloud Foundry environment. You can build mobile apps that run outside the Bluemix environment and use services that the mobile apps are exposed to. Bluemix can also host application code that the developer would rather run on a back-end server in a container-based environment. Web apps consist of the code that is required to be run or referenced at run time.
A service is a cloud extension that is hosted by Bluemix. The service provides functionality that is ready-for-use by the app's running code. The predefined services that are provided by Bluemix include database, messaging, push notifications for mobile apps, and elastic caching for web apps. You can create your own services in Bluemix. They can be simple utilities, such as the functions you might see in a runtime library, or they can be complex business logic that you might see in a business process modeling service or a database.
2.6 Cloud Foundry Apps, Containers, and Virtual Servers
Figure 2-4 Cloud Foundry Apps, Containers, and Virtual Servers
Notes:
Cloud Foundry Apps use the Bluemix architecture. That is, these apps are composed into droplets, run on a droplet execution agent (DEA), and are accessed through a Cloud Foundry router.
Containers and Virtual Servers are alternative ways to run and manage an app. They allow more control over the underlying infrastructure and configuration, but require more work by the developer.
This course focuses on Cloud Foundry Apps.
2.7 Containers vs. Virtual Servers
Figure 2-5 Containers versus Virtual Servers
Notes:
Containers and VMs have similar objectives: to isolate an application and its dependencies into a self-contained unit that can run anywhere. They both remove the need for physical hardware, allowing for more efficient use of computing resources.
As covered in Unit 1., “Introduction to cloud computing and IBM Bluemix” on page 1, Virtual Servers (or virtual machines), are created using a hypervisor. The hypervisor virtualizes the physical hardware to create a software-defined computer that runs its own operating system. Unless special software is installed for cloud management, an operating system that is running in a virtual machine does not have any awareness that it is running in a virtual machine. As shown in Figure 2-5, the VM packages the virtual hardware, a kernel or OS, and user space for each new VM.
Unlike a VM which provides hardware virtualization, a container provides operating-system-level virtualization.
A container library, such as Docker, separates different user spaces for each container. On the surface, these spaces may look exactly like a virtual machine to a user. The main difference between containers and virtual machines is that containers share the operating system kernel with other containers running on the machine. In virtual machines, this is not the case. This is why you may see a virtual machine running Linux on a Windows server, or Windows on a Linux server. But you will not see a container that runs Linux on anything other than a Linux server. The containers on that Linux server are separated out user spaces on that Linux server and the hardware is not virtualized. Data storage is managed differently in containers as well. In virtual machines, virtual disks are created and are similar to physical disks in that once you write something to the disk, it stays there until you delete it. With containers, you can make changes to the disk and then delete your changes when done.
2.8 Bluemix catalog: Boilerplates
Figure 2-6 Bluemix catalog: Boilerplates
Notes:
In IBM Bluemix, Boilerplates are packages of templates and sample applications. When you create an app with boilerplate, Bluemix configures the services for the application. Bluemix also provides you with the source code and documentation for the sample application in the boilerplate.
A boilerplate contains an app and its associated runtime environment and predefined services. You can use a boilerplate to quickly get up and running. For example, you can select the Mobile Cloud boilerplate to host mobile and web apps and accelerate development time of server-side scripts by using the mobile app template and SDK.
2.9 Bluemix catalog: Runtimes
Figure 2-7 Bluemix catalog: Runtimes
Notes:
A runtime is the set of resources that is used to run an app. Bluemix provides runtime environments as containers for different types of apps. The runtime environments are integrated as buildpacks into Bluemix, and are automatically configured for use.
Runtimes start with a simple templated example application that you can customize to meet your needs. These runtimes do not come with any services by default, but you can add and bind your own services later.
2.10 Bluemix catalog: Services
Figure 2-8 Bluemix catalog: Services
Notes:
Services are extensions to the cloud environment that IBM Bluemix hosts and manages.The predefined services that are provided by Bluemix include NoSQL and SQL databases, the ability to send push notifications to your mobile app, and automated language translation.
You can add services to your Bluemix application from the Bluemix catalog. Services provide a predefined endpoint that you can access from your application to use the predefined functionality of that service.
The infrastructure for services are completely managed by Bluemix, and your app needs to only focus on the provided endpoint. You can bind more than one app to a service to share services between your apps.
There are many Bluemix services and more are being added. Figure 2-8 shows a sample of the services available for IBM Watson.
2.11 Create a Bluemix application (1 of 3)
Figure 2-9 Create a Bluemix application (1 of 3)
Notes:
To create a Bluemix application perform the following steps:
1. Click Create an app
2. Select the type of app, either web or mobile application
3. Select a runtime from a wide array of available runtimes in Bluemix.
You can also indicate that you have code already, or use community buildpacks that provide even more runtimes than you see in the Bluemix catalog.
2.12 Create a Bluemix application (2 of 3)
Figure 2-10 Create a Bluemix application (2 of 3)
Notes:
From here, you can click View Details in Catalog to set your own domain name or further customize your app.
You can just click Continue, and you will be prompted for your application name. If you do not specify your own domain, your app will get the mybluemix.net domain, which is provided to all public user applications in Bluemix.
2.13 Bluemix application name must be unique across domain
Figure 2-11 Bluemix application name must be unique across domain
Notes:
By default, Bluemix hosts your application on the mybluemix.net domain. You do not share your memory and application instances with other IBM Bluemix accounts. You must choose a host name that is unique across all applications from all Bluemix users.You cannot create a Bluemix application with the same host name already in used by another application.The exercises in this course handle this issue by having each team use a randomly-generated key.
Your app’s name is different than its host name and only needs to be unique within your organization. You can have the same name as another user, as long as you do not have the same host name as another user. By default, Bluemix sets your hostname and your app name to be the same. The app name is for your reference only to use in scripts, commands to the CLI, and to find your app within the Bluemix UI. The application’s host name will become part of the application's route, which is how users access your app over the internet.
2.14 Create a Bluemix application (3 of 3)
Figure 2-12 Create a Bluemix application (3 of 3)
Notes:
Next, select your development style. You can:
Download the Eclipse Tools for Bluemix, which allow you to use the Bluemix APIs from the Eclipse integrated development environment.
Edit your app in your favorite text editor and use the Cloud Foundry command line to deploy.
Use the git command line client and Bluemix DevOps Services to deploy your app with a completely web-based approach.
2.15 Bluemix application overview
Figure 2-13 Bluemix application overview
Notes:
From the Bluemix application overview page you can:
View and adjust the memory resources that are used by the application
Start and stop your application
Navigate to your application as a user
Manage your application with Bluemix DevOps Services and add the source code of your app to a git repository
2.16 Bluemix dashboard: Environment health
Figure 2-14 Bluemix dashboard: Environment health
Notes:
The Cloud Foundry environment health view in the IBM Bluemix dashboard shows you the amount of memory you are using in your space and the number of services you are using in your space.
If you find that your organization is running low on memory, you can always stop an application without deleting it and start it again later when needed. If you are running out of available services, however, you must delete some to free up space.
The health view provides similar overviews for virtual servers and containers, but these are outside the scope of this course.
2.17 Testing applications through the application route
Figure 2-15 Testing applications through the application route
Notes:
The application route is the entry point for end-users into your application in Bluemix. You can host a REST service, web application, or web page through this route.
To view the application route, click the Open URL icon. You can access the application route for a running application only.The application route must be unique across all applications in the domain
2.18 Add a Bluemix service
Figure 2-16 Add a Bluemix service
Notes:
You can add a Bluemix service to your app by clicking Use Services or APIs and then selecting a service from the Bluemix Catalog. You must then provide a name for the service and the space you want it to run in, and select a plan for your service. Plans allow you to choose different “sizes” for the service, such as how much power you put behind it. For example, with some services you can choose whether you share hardware or use dedicated hardware.
You can bind the service to your app from this page, or just leave the service unbound. If you leave the service unbound, Bluemix will create and provide credentials for accessing the service, which you can access from within the service dashboard. If you bind the service to an app, the credentials will show up in the application's environment variables.
The Credential Name field is used for creating multiple credentials to the same service in case you need further control over who can use the service. You can leave this field at its default value.
2.19 Bind a service to an application
Figure 2-17 Bind a service to an application
Notes:
To bind the service to your application, go to your application overview page and select BIND A SERVICE OR API. Bluemix will list the services that you have created in your space that are compatible with your service and runtime environment. Some services are specific to certain runtimes, such as a Java Runtime monitor, and might not be applicable or indeed usable from your application.
When you add a service, Bluemix creates a new or additional instance of that service in your organization.
When you bind a service to an app, Bluemix creates a set of credentials to access that service and places the connection information for this service in the app's environment variables.
2.20 Bluemix environment variables
Figure 2-18 Bluemix environment variables
Notes:
Environment variables contain the environment information of a deployed application on Bluemix. Bluemix automatically populates the environment variable VCAP_SERVICES with the services that you bound to your Bluemix application.
With the USER-DEFINED environment variables, you can set configuration settings without hard coding the values in your application. For example, you can save the web service endpoint, user name, and password for a cloud-based database as a user-defined environment variable.
2.21 Bluemix organizations and users (team members)
Figure 2-19 Bluemix organizations and users (team members)
Notes:
Organizations, users, and spaces are the building blocks for organizing resources in the Bluemix environment. The organization is the main organizational unit for Bluemix.
Organizations are defined by the following items:
Users or team members
Domains
Quota
In Bluemix, you can use organizations to enable collaboration among team members and to facilitate the logical grouping of project resources.
A user or team member has a role with basic permissions in organizations and spaces. All users must belong to at least one organization. Users can belong to more than one organization, which is how you can share control over applications and service instances.
2.22 Bluemix domains and quota
Figure 2-20 Bluemix domains and quota
Notes:
Domains provide the route on the internet that is allocated to the organization:
A route has a sub-domain and a domain.
A sub-domain is the hostname, which is typically the application name.
A domain might be a system domain, or a custom domain that you registered for your application.
The default domain name is mybluemix.net.
The domain and the route determine how users interact with your Bluemix applications over the network
Quota represents the resource limits for the organization, including the number of services and the amount of memory that can be allocated for use by the organization:
Quotas are assigned when organizations are created.
Any application or service in a space of the organization contributes to the usage of the quota.
With the Pay-As-You-Go or subscription plans, you can adjust your quota for Cloud Foundry applications and containers as the needs of your organization change.
2.23 Bluemix organizations: Spaces
Figure 2-21 Bluemix organizations: Spaces
Notes:
Spaces in Bluemix are the next level down from organizations:
A space is a mechanism to group a set of applications, services, and team members within an organization.
An organization can have multiple spaces, but these spaces must have unique names within an organization.
Two organizations can have their own spaces with the same name, but two organizations cannot share the same space.
You must belong to an organization to belong to one of its spaces.
You must be a developer in the space in which an application or service exists to interact with that application or service as a Bluemix user.
Bluemix users typically use spaces to delineate different types of deployment environments, such as development, testing, staging and production.
2.24 Bluemix organizations: User roles
Figure 2-22 Bluemix organizations: User roles
Notes:
Users have roles in both spaces and organizations:
The organization manager controls who has access to the organization.
The billing manager can view usage information for the organization.
The auditor can view application and service content in the organization.
Space manager can control who has access to the space.
Space developer can create, delete, and manage apps and services within the space.
Space auditors have read only access to settings, logs, apps, and services.
2.25 Managing Bluemix organizations
Figure 2-23 Managing Bluemix organizations
Notes:
The organization’s managers can invite users to the organization and assign them the various roles.
2.26 Checkpoint questions
Figure 2-24 Checkpoint questions
Notes:
(none)
2.27 Checkpoint answers
Figure 2-25 Checkpoint answers
Notes:
(none)
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.31.22