Add base files.

This commit is contained in:
Ben Kochie 2018-12-16 14:41:55 +01:00
commit f71f3eab80
Failed to generate hash of commit
4 changed files with 170 additions and 0 deletions

3
CHANGELOG.md Normal file
View file

@ -0,0 +1,3 @@
# Change Log
\* *This Change Log was automatically generated by [github_changelog_generator](https://github.com/skywinder/Github-Changelog-Generator)*

75
CONTRIBUTING.md Normal file
View file

@ -0,0 +1,75 @@
# Contributor Guideline
This document provides an overview of how you can participate in improving this project or extending it. We are grateful for all your help: bug reports and fixes, code contributions, documentation or ideas. Feel free to join, we appreciate your support!!
## Communication
### IRC
You can talk with us on #cloudalchemy channel on freenode.
### GitHub repositories
Much of the issues, goals and ideas are tracked in the respective projects in GitHub. Please use this channel to report bugs.
## git and GitHub
In order to contribute code please:
1. Fork the project on GitHub
2. Clone the project
3. Add changes (and tests)
4. Commit and push
5. Create a merge-request
To have your code merged, see the expectations listed below.
You can find a well-written guide [here](https://help.github.com/articles/fork-a-repo).
Please follow common commit best-practices. Be explicit, have a short summary, a well-written description and references. This is especially important for the merge-request.
Some great guidelines can be found [here](https://wiki.openstack.org/wiki/GitCommitMessages) and [here](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
## Releases
We try to stick to semantic versioning and our releases are made by CI pipeline. It is done by assigning a keyword (in a way similar to travis [`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build#Skipping-a-build)) to a commit with merge request. Available keywords are (square brackets are important!):
* `[patch]`, `[fix]` - for PATCH version release
* `[minor]`, `[feature]`, `[feat]` - for MINOR version release
* `[major]`, `[breaking change]` - for MAJOR version release
## Changelog
Changelog is generateg automatically on every merged Pull Request and all information is taken from github issues, PRs and labels.
## Expectations
### Keep it simple
We try to provide production ready ansible roles which should be as much zero-conf as possible but this doesn't mean to overcomplicate things. Just follow [KISS](https://en.wikipedia.org/wiki/KISS_principle).
### Be explicit
* Please avoid using nonsensical property and variable names.
* Use self-describing attribute names for user configuration.
* In case of failures, communicate what happened and why a failure occurs to the user. Make it easy to track the code or action that produced the error. Try to catch and handle errors if possible to provide improved failure messages.
### Add tests
Currently we are using two test scenarios located in [/molecule](molecule) directory. First ([default](molecule/default/molecule.yml)) one is testing default configuration without any additional variables, second one ([alternative](molecule/alternative/molecule.yml)) is testing what happens when many variables from [/defaults/main.yml](defaults/main.yml) are changed. When adding new functionalities please add tests to proper scenarios. Tests are written in testinfra framework and are located in `/tests` subdirectory of scenario directory (for example default tests are in [/molecule/default/tests](molecule/default/tests)).
More information about:
- [testinfra](http://testinfra.readthedocs.io/en/latest/index.html)
- [molecule](https://molecule.readthedocs.io/en/latest/index.html)
### Follow best practices
Please follow [ansible best practices](http://docs.ansible.com/ansible/latest/playbooks_best_practices.html) and especially provide meaningful names to tasks and even comments where needed.
Our test framework automatically lints code with [`yamllint`](https://yamllint.readthedocs.io) and [`ansible-lint`](https://github.com/willthames/ansible-lint) programs so be sure to follow their rules.
Remember: Code is generally read much more often than written.
### Use Markdown
Wherever possible, please refrain from any other formats and stick to simple markdown.

21
LICENSE Normal file
View file

@ -0,0 +1,21 @@
The MIT License (MIT)
Copyright (c) 2017-2018 Pawel Krupa and Roman Demachkovych
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

71
README.md Normal file
View file

@ -0,0 +1,71 @@
# Ansible Role: CoreDNS
[![Build Status](https://travis-ci.org/cloudalchemy/ansible-coredns.svg?branch=master)](https://travis-ci.org/cloudalchemy/ansible-coredns)
[![License](https://img.shields.io/badge/license-MIT%20License-brightgreen.svg)](https://opensource.org/licenses/MIT)
[![Ansible Role](https://img.shields.io/badge/ansible%20role-cloudalchemy.coredns-blue.svg)](https://galaxy.ansible.com/cloudalchemy/coredns/)
[![GitHub tag](https://img.shields.io/github/tag/cloudalchemy/ansible-coredns.svg)](https://github.com/cloudalchemy/ansible-coredns/tags)
[![IRC](https://img.shields.io/badge/irc.freenode.net-%23cloudalchemy-yellow.svg)](https://kiwiirc.com/nextclient/#ircs://irc.freenode.net/#cloudalchemy)
## Description
Deploy [CoreDNS](https://github.com/coredns/coredns) using ansible.
## Requirements
- Ansible >= 2.5 (It might work on previous versions, but we cannot guarantee it)
## Role Variables
All variables which can be overridden are stored in [defaults/main.yml](defaults/main.yml) file as well as in table below.
| Name | Default Value | Description |
| ---------------------------- | -------------- | -----------------------------------|
| `coredns_version` | 1.3.0 | CoreDNS package version |
| `coredns_dns_port` | 53 | Port on which CoreDNS will listen for DNS requests |
| `coredns_config` | | The configuration of the [Corefile](https://coredns.io/manual/toc/#configuration) |
## Example
### Playbook
Use it in a playbook as follows:
```yaml
- hosts: all
roles:
- cloudalchemy.coredns
```
### Demo site
We provide demo site for full monitoring solution based on prometheus and grafana. Repository with code and links to running instances is [available on github](https://github.com/cloudalchemy/demo-site) and site is hosted on [DigitalOcean](https://digitalocean.com).
## Local Testing
The preferred way of locally testing the role is to use Docker and [molecule](https://github.com/metacloud/molecule) (v2.x). You will have to install Docker on your system. See "Get started" for a Docker package suitable to for your system.
We are using tox to simplify process of testing on multiple ansible versions. To install tox execute:
```sh
pip install tox
```
To run tests on all ansible versions (WARNING: this can take some time)
```sh
tox
```
To run a custom molecule command on custom environment with only default test scenario:
```sh
tox -e py27-ansible25 -- molecule test -s default
```
For more information about molecule go to their [docs](http://molecule.readthedocs.io/en/latest/).
If you would like to run tests on remote docker host just specify `DOCKER_HOST` variable before running tox tests.
## Travis CI
Combining molecule and travis CI allows us to test how new PRs will behave when used with multiple ansible versions and multiple operating systems. This also allows use to create test scenarios for different role configurations. As a result we have a quite large test matrix which will take more time than local testing, so please be patient.
## Contributing
See [contributor guideline](CONTRIBUTING.md).
## License
This project is licensed under MIT License. See [LICENSE](/LICENSE) for more details.