AnsibleWorks Galaxy now available - find, download, share, rate, and review Ansible roles

Archives Ansible Project
,
1

Hi everyone,

Today’s a great day as we get to unveil something that’s been in progress for the last few months!

People have been asking, “what’s the best way to reuse Ansible content”. The answer of course is roles - We built roles in Ansible 1.2 - http://ansibleworks.com/docs/playbooks_roles.html#roles. Role dependencies and defaults were added shortly thereafter in 1.3.

But how do we share roles?

We thought about this a lot and built … AnsibleWorks Galaxy. If you were at AnsibleFest in San Francisco you got an early preview from James Cammarata, though we’ve since retooled many things from the ground up! What’s Galaxy? Ansible Galaxy is an automation content site designed from the ground up with an emphasis on being very dynamic — offering up a lot of new ways to find content.

Why is it called Galaxy? To us, Ansible is sort of like the Mos Eisley Cantina (we assume you have seen the original Star Wars, if not, please rectify this ASAP). We’re just one spot on one planet. All the content and diaspora in the Ansible community, all that we create, compromises the Galaxy.

Galaxy is structured around roles. You download the roles you like, then you write very simple play books that assemble all the roles together with roles you also write yourself. Roles can contain tasks, default variables, all you want, and special metadata provided in the role instructs Galaxy about how to display it, along with a README.

  • hosts: webservers

roles:

  • { role: author1.foo, x: 27 }

  • { role: author2.magic, port: 5000 }

Galaxy has a lot of neat features which you should be able to explore pretty quick.

At the initial phase, we’ve made signup as painless as we could — you can login with a local account, but you can also login with OAuth from Twitter, GitHub, or Google+. (We just use this for login, so we won’t tweet for you or anything). You can also link social accounts later if you sign up first with a local account, but we expect social auth is the way to go for many of you.

Once you log in, from the “Explore” page, you can see not only the top roles in each category, but also the top reviewers, top authors, new roles, and new authors. You can browse the users arbitrarily and see what they have contributed and reviewed.

When we started Galaxy, a lot of our design influences were from consumer sites — things like iTunes, Flickr (Explore), and most significantly … beeradvocate.com! For this reason you’ll see linked reviews and ratings, ratings with structure, and highlighted reviews from AnsibleWorks employees. It’s designed to help you find what’s good very very clearly, and explore other things you might be interested in.

Once you find something you like, the roles detail page will tell you what command line to use to install it.

There’s a command line tool that’s embedded in Ansible 1.4.2 — which is incidentally on PyPi exactly right now and a pip install away, or otherwise available on http://ansibleworks.com/releases/ — and will soon make it’s way to the distributions.

This is all documented on the “About/Help” page of galaxy, but the command line tool can help set you up with a scaffold of a new role, and can also download roles and dependencies. The ansible-galaxy CLI is of course open source, so it can take pull requests and get much smarter (I’ve heard some nice requests for things like storing previous versions), but we’d probably enjoy a discussion on ansible-devel@googlegroups.com first as it’s still pretty new and we would want to reduce duplicate efforts!

Galaxy is all backed by GitHub, so to share a new role, all you need to do is a host a GitHub repository as instructed on the “About/Help” page of Galaxy, and then log in, and hit “Add Role”. (You can also have versions of roles by using tags on the repo, if you want!)

We should also point out that our RESTful API is fully browse-able too! Go to http://galaxy.ansibleworks.com/api to see for yourself! You may also enjoy watching Firebug as you are using the web application. If you like the API, you may wish to know it shares a lot in common with the API design and UI of AWX - http://ansibleworks.com/ansibleworks-awx, which provides not only a UI and central server solution for Ansible, but also a great API for embedding. Both use Angular.js and are powered by Bootstrap, which we both pretty much love for frontend development.

Galaxy will get some refreshes periodically and is currently in “beta”, so let us know what your thoughts and ideas! Beta just means there may be some kinks not worked out — and we may be revising the interface some. All your role data you upload will stay there even as it goes out of beta, and that applies to reviews and comments as well.

Galaxy comes to you mostly through a lot of hard work from two great AnsbileWorks engineers — James Cammarata and Chris Houseknecht, so thanks very much to both of them for this — and thanks to all of you for waiting so long for this, we wanted to take time to do it right, and hope you really like it. Of course, we’re not done either! Please take a look and let us know your thoughts!

http://galaxy.ansibleworks.com/

2

Michael DeHaan <michael@ansibleworks.com> writes:

Hi everyone,

[…]

Galaxy comes to you mostly through a lot of hard work from two great
AnsbileWorks engineers — James Cammarata and Chris Houseknecht, so thanks
very much to both of them for this — and thanks to all of you for waiting
so long for this, we wanted to take time to do it right, and hope you
really like it. Of course, we’re not done either! Please take a look
and let us know your thoughts!

http://galaxy.ansibleworks.com/

Awesome.

I really like the API, even though I got errors browsing to
https://galaxy.ansibleworks.com/api/v1/categories/2/ but, hey, it’s
brand new!

I’d like to know your policy regarding eventual competing or duplicate
roles: will you “let the market decide” or will you try to favor only
the best of breed?

3

​Wonderful! I have been looking forward to this, and it seems to fulfill my
expectations!​ Thanks!

I have a couple of questions though.

How would we handle roles which needs modules that are not in core?
Will there be a way to also share modules?

I was also thinking it might be a good idea to also manage the ansible
version a particular role would need?

Thumb up for this nice product!

  Serge

4

Thanks for the report, we’ll fix it up shortly (I’m keeping a list of feedback comments).

Meanwhile, the record that this REST entry would return is the same as you would see in the list.

As for different roles for the same topic, we’re going to allow duplicates and let the rating system sort them out – unless it becomes too confusing, in which case we may moderate some.

We haven’t decided yet but may cull some roles in some very very rare cases, such as if we see reviews it chmod 700’s “/” or something … but are not going to be a gatekeeper on incoming content. The review system will be the main thing for that.

5

Good ideas.

First off, the ansible version a particular role might need is already a field in the metadata and is displayed. We do however need to make the CLI enforce this, so if you are downloading a 1.5/1.6/future-using feature, the 1.4.2 CLI would yell at you, etc. Given, we’re unlikely to update the 1.4.2 CLI, but a future CLI, of course :slight_smile:

Secondly, yes, there isn’t currently (yet) a way to store modules in a “/library” subdirectory of the role and have that added to the playbook module path. I’m open to this, however, I don’t want it to discourage contribution of good generally-useful modules to core, and believe it might do so, so we’d probably want to at least verbally discourage it. It seems the desired behavior would be to insert things at the end of the module path to make sure no role could override a stock module, to avoid surprises, but that we should do this.

6

A quick update:

For those that are uploading roles, note that you need to edit the meta/main.yml generated by the CLI to remove the “or higher” in the Ansible version for the upload to be accepted.
This is already fixed on the development branch of Ansible and we’ll be updating Ansible 1.4.2 shortly to include the updated CLI. (That will also understand your ansible.cfg roles_path).

Things look very very stable – Various other improvements to Galaxy itself will role out later in the beta period.

Thanks all!

7

I love this addition.

Continuing from our conversation on Twitter, I can offer a few suggestions and comments:

  • As mentioned, the ability to have multiple roles in just 1 repo would make contributing and maintaining roles much simpler.

  • Scaffolding is nice, but if we already have a functional role, then it becomes unnecessary. I think the most important is to ensure the meta file exists, and the proper directory structure is in place (rolename/{tasks,meta,vars,files}) etc. Perhaps a cli addition to verify the a role’s dir/structure prior to uploading it?

  • In regards to versioning, I like the idea of placing the version number in the meta file. What if you tracked/map the meta file/version changes with the git commit SHA? Then you can provide a download URL like this: https://github.com/aw/ansible-galaxy-vagrant/archive/fbd110c5fb42281971955a1c654af1c8ae261278.zip

Just some thoughts. In any case, great effort!

<3

AW

8

​+1

- one role per repo could potentially yield lots of repo's...
- that one "master" repo​ could t hen benefit of some better naming, whilst
now the name of the repo becomes the role name, making it not too nice to
make it clear in the name it's about an ansible role

9

one thing suggested in irc, a link to the role’s repo, right now you can click on Issues and get there, but a clear and direct link would be nice.

10

We’re considering supporting more than one role per repo (subdirs), just need to think about how to handle tags.

We also are going to support different role names than the repo name, etc – and definitely – yes, add the direct github link instead of just issues – we had that earlier but it dropped off recently :slight_smile:

There’s also a list of about 20 other awesome things :slight_smile:

11

Hi Michael,

I think somethings wrong with the Google Sign in:

Fout:invalid_client
Bad request.

The link as shown:

https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&state=31U02EY6YAW7&redirect_uri=https%3A%2F%2Fgalaxy.ansibleworks.com%2Faccounts%2Fgoogle%2Flogin%2Fcallback%2F&response_type=code&client_id=ansibleworks.com

Is what I’m getting back when I try.

Mark

12

Google is waiting on DNS propogation for some people still.

– Michael

13

Hello,

great work on galaxy !

here is an idea (easier said than done :wink: :

step 1/ imagine a way to include tests of a role inside a galaxy role
step 2/ have an “role test cluster” where roles & tests would be played automatically against whatever distribution you can think of
step 3/ win an automatic feedback of what platforms the role is compatible with

think of it as the travis-ci for galaxy roles.

it could be interesting because i suppose that many role developers are targeting only 1 or 2 platforms and there is a risk of platform fragmentation in the galaxy roles.

Jerome

14

I need some kind of way to see what the Galaxy role is.

There’s a button for “issue tracker” that takes me from the Role on Galaxy to a Github page for the Role, and that works, but it didn’t occur to me that it was going to bring me to a place where I could see the code. I’d suggest that the version history should link to the tag/branch/whatever that underlies it?

15

This is a known thing, direct GH links coming soon!

– Michael