You must have permission to use a specific namespace on the Nimbella platform in order to deploy a nim project and use many other nim capabilities. A Nimbella namespace comes with storage resources which are managed as part of the namespace.
This section contains information about how to create a Nimbella namespace, view the credential store, and perform other tasks involving namespaces.
Create a Nimbella namespace
Here’s how to create a Nimbella workspace in
If you have not yet downloaded and installed the Nimbella Command Line Tool:
Visit nimbella.com and press the signup button (it's free). Follow instructions from that point.
If you have already downloaded and installed the Nimbella Command Line Tool:
After going through the signup process (which typically takes one or two minutes),
nim will return having fully provisioned your account. Occasionally, if the process takes too long,
nim may time out and encourage you to do another
nim auth login in a minute or two. The second attempt should succeed quickly.
In general (e.g.) when switching to a different machine you can just issue
This will connect the tool to your account (it may or may not ask for identification again, depending on whether or not your browser remembers this information).
View the credential store
A typical namespace is provisioned with the following:
- A web content file store, and a second file store for data storage. These are always provided as a pair and summarized as 'File-Store' when presented in a list.
- A key-value store implemented using a Redis instance.
- A DNS domain name for web content
- A set of OpenWhisk resources
After you’ve created a namespace, you can view it and information about it in the credential store.
To view the credential store in nim:
- Use the
auth listcommand, as follows:
As a new user, your credential store has only one entry, but, if you or your team acquires more namespaces, there can be multiple entries. Here’s more information about the table displayed in the response:
- The Current column displays
yesfor exactly one namespace.
- The Nimbella deployer will deploy this namespace in the absence of other directives.
- This entry is also marked by a check mark for added emphasis
- The File-Store column indicates whether the namespace has provision for web content storage as discussed in Adding static web content. There is also a second object storage bucket available for general use, not connected to the web.
- The Key-Val column indicates whether the namespace has a Redis key-value storage instance available for use by actions.
- The Production and Project columns become meaningful as you begin to define Nimbella projects and wish to tie namespaces to projects.
Create and manage multiple namespaces
There are a number of reasons why it can be useful to have multiple namespaces. For example, while multiple applications can share a namespace, there are also good reasons to isolate them.
To create additional namespaces:
- Contact Nimbella Support.
- Identify yourself as an existing developer and provide the email or GitHub account you used for signing up initially.
- Wait for an email to arrive containing instructions for adding the additional namespace to your credential store.
To view all of your namespaces:
Follow the procedure to view your credential store. A newly added namespace is automatically set as current, indicated by a checkmark and a yes in the Current column.
Switch between namespaces
If you have more than one namespace, you can switch between them without needing to log into your account again by using the following command:
This changes the target namespace for future project deployments. Most namespace names are long and tedious to type, so we provide an abbreviation capability.
will switch to a namespace uniquely identified by the characters
dt followed by other characters.
Manage multiple namespaces
The easiest way to manage multiple namespaces is to maintain the rule that each namespace is tied to a project and each project is tied to one or two namespaces. To do this, add the following top-level directive to a project.yml configuration file for each project:
A more complete explanation of how
targetNamespace affects project deployment is provided in Tieing namespaces to projects.
There are more complex development scenarios, in which you would not want to correlate projects and namespaces so strongly. For those cases, we also provide the
--target directive of the
project deploy command:
If your project has a project.yml configuration file with a
targetNamespacedirective and also uses the
--targetoption in a
project deploycommand, the latter takes precedence.
For more information about using project.yml files to configure more complex projects, see Adding Project Configuration.