Skip to content

Latest commit

 

History

History
226 lines (158 loc) · 7.89 KB

cloudify_faq_devops_cloud.textile

File metadata and controls

226 lines (158 loc) · 7.89 KB
layout title category publish abstract pageord
bt_wiki
Frequently Asked Questions
FAQ
true
Contains Frequently Asked Questions and answers
1

Q: How do I get cloudify?

A: You can download it here .


Q: How do I install Cloudify?

A: Feel free to check out our documentation -


If you need additional help, you can contact us.

Back to top

Q: Which clouds do you support?

A: Our Cloud Driver has built-in implementations for the following:
  • Microsoft Azure
  • OpenStack
  • Citrix Cloud Stack (Previously Cloud.Com Product)
  • EC2
  • Rackspace
  • Terramark


In general: Cloudify works with any cloud that supports the JClouds API.

Back to top

Q: Can I remove a service after I deploy an application?

A: Yes.
Assuming that your service is called myServiceName:

Run the following command from Cloudify CLI: uninstall-service myServiceName

Back to top

Q: Can I add a service after I deploy an application?

A: Yes. Assuming that your service is called myServiceName and is located in /user/myApps/currApp/:

Run the following command from Cloudify CLI: install-service /user/myApps/currApp/myServiceName

Back to top

Q: I deployed a Tomcat service and now I have a new WAR file.
Do I need to re-install the whole application?

A: You don’t need to re-install an application in order to update a WAR file.

In order to do that, when you install an application, you must add an “updateWar” custom command (in your recipe’s custom commands section) to your recipe.
You can read more about custom commands here .

Back to top

Q: Where can I get updated about new releases?

A: Our Release notes page is here .

Back to top

Q: What is Cloudify’s pricing?

A: Cloudify has a number of editions, one of which is completely free production usage, with no size limits. The other editions are paid editions, and differ from the free edition in that they include commercial support from GigaSpaces and premium features. You can read about it here

Back to top

Q: What application stacks can I use?

A: Cloudify enables you to on-board any Application onto any Cloud. We wanted to provide a flexible yet simple mechanism to deploy and manage applications on the cloud. But we also wanted it to be flexible enough to support any kind of application. In other words, we decided that our platform would support your application no matter what application stack you use (Java/Spring, Java EE, PHP, .NET, Ruby on Rails or others), whether you are using a relational (such as MySQL) or non-relational (e.g., Apache Cassandra) data store, or if you choose to add other middleware components. Regardless of your application set-up, you can still use Cloudify to… Cloudify it.


Back to top

Q: Is Cloudify a service?

A: No, cloudify is a downloadable software product that can run on your laptop, data center or any cloud environment.


Back to top

Q: Is Cloudify open source?

A: Most of Cloudify’s components are open sourced. The sources can be found on GitHub and are licensed under the Apache2 license .

Some parts of Cloudify are still not open sourced, but we plan to gradually open source most of them over the next few months.


Back to top

Q: How can I contribute to the Cloudify open source project?

A: We are more than happy to get your controbutions. You can find all the details on how to become a contributor in this page.


Back to top

Q: What does the test-recipe command do?
What is the difference between test-recipe and install-application?

A: The test-recipe enables you to test one service recipe of yours.
The test-recipe actually runs a service recipe (and all its lifecycle event handlers).
It does NOT require a bootsrap, nor does it perform one, so obviously, it does NOT create a management machine.


P.S. :
Currently Cloudify does NOT enable you test an application recipe, only a service recipe.


Back to top

Q: Where will the serviceDirectory point to?
If I have two service instances.
Will the statement ${serviceContext.serviceDirectory} be identical for both them on localcloud?

A: No.
The ${serviceContext.serviceDirectory} is actually the instance’s working directory.
Each instance has its own working directory on every cloud (public, private and localcloud).
Assuming that your application is named myApp and your service is named myService:
  • On localcloud:
    • The 1st instance’s working directory will be <Cloudify Root>/work/processing-units/myApp_myService_1/ext
    • The second’s will be <Cloudify Root>/work/processing-units/myApp_myService_2/ext.
  • On a real cloud:
    • The 1st instance’s working directory will be remoteDirectory/work/processing-units/myApp_myService_1/ext
    • The second’s will be remoteDirectory/work/processing-units/myApp_myService_2/ext.

Note that remoteDirectory should be set in the provider section in <Cloudify Root>/clouds/YOUR_CLOUD_PROVIDER_NAME/YOUR_CLOUD_PROVIDER_NAME-cloud.groovy .


Back to top

Q: Ant with proxy:
I am using AntBuilder in my install lifecycle event handler script and I need to get a resource from a url.
I need a proxy with my http connection.
How do I make it work ?

A:


Back to top

Q: What should I have on my environment prior to using Cloudify?

A: You can read about Cloudify’s prerequisites here.


Back to top

Q: Where can I suggest a feature or report a bug?

A: We track all our issues in our public JIRA.



Back to top

Q: How can I set environment variables that will be known to any process of any service?

A: You can read about Setting OS variables in the cloud Driver configuration here.


Back to top