Add base files.
This commit is contained in:
commit
f71f3eab80
3
CHANGELOG.md
Normal file
3
CHANGELOG.md
Normal 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
75
CONTRIBUTING.md
Normal 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
21
LICENSE
Normal 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
71
README.md
Normal 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.
|
Loading…
Reference in a new issue