In last week\u2019s 0.9 release we added support in Rancher for users to
\ncreate new deployment environments that can be shared with colleagues.
\nThese docker environments are called projects, and are an extension of the
\nGitHub OAuth integration we added to Rancher last month. The focus of
\nprojects is to allow teams to collaborate on Docker environments, and
\nsince our user management is connected with GitHub today, we leverage
\nstandard GitHub abstractions, such as users, teams and organizations, to
\nsupport Rancher Projects.<\/p>\n
(If you haven\u2019t read my earlier post on This demo will show you how to create projects on Rancher for various One of the most obvious use cases for this new feature is to User projects allow resources to be orchestrated by an individual user. Team projects allow users to allocate resources and provide access to a Organization level projects allocate resources and provides access to ###<\/p>\n
\nGitHub OAuth on Rancher<\/a>,
\nI would recommend you to read it as it provides an introduction to
\nRancher authentication using GitHub.)<\/p>\nProjects demo<\/h2>\n
\nlevels of access control.<\/p>\nThe project use case<\/h2>\n
\ncontrol access to environments and resources within an organization.
\nFor example, a common request from users is to have development teams
\nand production teams own their own environments and resources. With
\nprojects, access to production environments can be shared among an
\napproved group, and restricted from unauthorized users. At the same
\ntime, developers can have unfettered access to development environments,
\nand can collaborate on testing, confident it will not be accessed by
\nanyone else. Every project is a fully isolated environment for managing
\nresources and deploying containers. Anyone who has access to a project
\ncan register new computing resources (virtual machines or physical
\nservers) and deploy containers, configure networking, and consume all of
\nthe other capabilities of Rancher. Rancher supports three kinds of
\nprojects<\/p>\n\n
User projects<\/h3>\n
\nThey are meant to be used when a single user is the sole manager of the
\nresources. Users can create multiple projects for different environments
\nthey are working on. One of the caveats of this type of project is
\nthat, users can create \u201cuser-level\u201d projects only for themselves.<\/p>\nTeam projects<\/h3>\n
\nteam of people. Team projects are ideal for collaborating with a
\npredefined GitHub group. In the use case above, an organization could
\ncreate separate team projects for the dev and operations teams.
\nGiving both teams the ability to access their own resources.<\/p>\nOrg projects<\/h3>\n
\nall members of the organization. For example, if you wanted to create a
\nresource called demo, that everyone in your organization could
\norchestrate, this type of project would be the ideal choice. I hope this
\nproject feature will be useful to you and your team. If you\u2019d like to
\nget more information on using Rancher, or see it in action, please
\ndon\u2019t hesitate to schedule a demo.<\/p>\n