mirror of
https://github.com/clearlinux/docs.git
synced 2026-09-07 14:41:29 +00:00
pulled descriptions from registry.hub
This commit is contained in:
Joe Ferguson
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
A collection of common build dependencies, especially useful for installing arbitrary modules such as gems where build dependencies can't easily be determined beforehand.
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/buildpack-deps/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/gcc/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/golang/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,22 @@
|
||||
$ docker run hello-world
|
||||
Hello from Docker.
|
||||
This message shows that your installation appears to be working correctly.
|
||||
|
||||
To generate this message, Docker took the following steps:
|
||||
1. The Docker client contacted the Docker daemon.
|
||||
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
|
||||
(Assuming it was not already locally available.)
|
||||
3. The Docker daemon created a new container from that image which runs the
|
||||
executable that produces the output you are currently reading.
|
||||
4. The Docker daemon streamed that output to the Docker client, which sent it
|
||||
to your terminal.
|
||||
|
||||
To try something more ambitious, you can run an Ubuntu container with:
|
||||
$ docker run -it ubuntu bash
|
||||
|
||||
For more examples and ideas, visit:
|
||||
http://docs.docker.com/userguide/
|
||||
|
||||
$ docker images hello-world
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
hello-world latest 565a9d68a73f 26 hours ago 922 B
|
||||
@@ -0,0 +1 @@
|
||||
Hello World!
|
||||
@@ -0,0 +1,48 @@
|
||||
$ docker run hello-world
|
||||
Hello from Docker.
|
||||
This message shows that your installation appears to be working correctly.
|
||||
|
||||
To generate this message, Docker took the following steps:
|
||||
1. The Docker client contacted the Docker daemon.
|
||||
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
|
||||
(Assuming it was not already locally available.)
|
||||
3. The Docker daemon created a new container from that image which runs the
|
||||
executable that produces the output you are currently reading.
|
||||
4. The Docker daemon streamed that output to the Docker client, which sent it
|
||||
to your terminal.
|
||||
|
||||
To try something more ambitious, you can run an Ubuntu container with:
|
||||
$ docker run -it ubuntu bash
|
||||
|
||||
For more examples and ideas, visit:
|
||||
http://docs.docker.com/userguide/
|
||||
|
||||
$ docker images hello-world
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
hello-world latest 565a9d68a73f 26 hours ago 922 B
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/hello-world/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
Java is a computer programming language that is concurrent, class-based, object-oriented, and specifically designed to have as few implementation dependencies as possible.
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/java/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,20 @@
|
||||
# What is MongoDB?
|
||||
|
||||
MongoDB (from "humongous") is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster. Released under a combination of the GNU Affero General Public License and the Apache License, MongoDB is free and open-source software.
|
||||
|
||||
First developed by the software company 10gen (now MongoDB Inc.) in October 2007 as a component of a planned platform as a service product, the company shifted to an open source development model in 2009, with 10gen offering commercial support and other services. Since then, MongoDB has been adopted as backend software by a number of major websites and services, including Craigslist, eBay, Foursquare, SourceForge, Viacom, and the New York Times, among others. MongoDB is the most popular NoSQL database system.
|
||||
|
||||
> [wikipedia.org/wiki/MongoDB](https://en.wikipedia.org/wiki/MongoDB)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a mongo instance
|
||||
docker run --name some-mongo -d mongo
|
||||
|
||||
This image includes `EXPOSE 27017` (the mongo port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-mongo:mongo -d application-that-uses-mongo
|
||||
|
||||
## ... or via `mongo`
|
||||
docker run -it --link some-mongo:mongo --rm mongo sh -c 'exec mongo "$MONGO_PORT_27017_TCP_ADDR:$MONGO_PORT_27017_TCP_PORT/test"'
|
||||
@@ -0,0 +1 @@
|
||||
MongoDB is a document database that provides high performance, high availability, and easy scalability.
|
||||
@@ -0,0 +1,46 @@
|
||||
# What is MongoDB?
|
||||
|
||||
MongoDB (from "humongous") is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB eschews the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster. Released under a combination of the GNU Affero General Public License and the Apache License, MongoDB is free and open-source software.
|
||||
|
||||
First developed by the software company 10gen (now MongoDB Inc.) in October 2007 as a component of a planned platform as a service product, the company shifted to an open source development model in 2009, with 10gen offering commercial support and other services. Since then, MongoDB has been adopted as backend software by a number of major websites and services, including Craigslist, eBay, Foursquare, SourceForge, Viacom, and the New York Times, among others. MongoDB is the most popular NoSQL database system.
|
||||
|
||||
> [wikipedia.org/wiki/MongoDB](https://en.wikipedia.org/wiki/MongoDB)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a mongo instance
|
||||
docker run --name some-mongo -d mongo
|
||||
|
||||
This image includes `EXPOSE 27017` (the mongo port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-mongo:mongo -d application-that-uses-mongo
|
||||
|
||||
## ... or via `mongo`
|
||||
docker run -it --link some-mongo:mongo --rm mongo sh -c 'exec mongo "$MONGO_PORT_27017_TCP_ADDR:$MONGO_PORT_27017_TCP_PORT/test"'
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mongo/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,19 @@
|
||||
# MySQL
|
||||
MySQL is (as of March 2014) the world's second most widely used open-source relational database management system (RDBMS). It is named after co-founder Michael Widenius's daughter, My. The SQL phrase stands for Structured Query Language.
|
||||
|
||||
MySQL is a popular choice of database for use in web applications, and is a central component of the widely used LAMP open source web application software stack (and other 'AMP' stacks). LAMP is an acronym for "Linux, Apache, MySQL, Perl/PHP/Python." Free-software-open source projects that require a full-featured database management system often use MySQL.
|
||||
|
||||
> [wikipedia.org/wiki/MySQL](https://en.wikipedia.org/wiki/MySQL)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a mysql instance
|
||||
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql
|
||||
|
||||
This image includes `EXPOSE 3306` (the mysql port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-mysql:mysql -d application-that-uses-mysql
|
||||
|
||||
## ... or via `mysql`
|
||||
docker run -it --link some-mysql:mysql --rm mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'
|
||||
@@ -0,0 +1 @@
|
||||
MySQL is the world's second most widely used open-source relational database management system (RDBMS).
|
||||
@@ -0,0 +1,45 @@
|
||||
# MySQL
|
||||
MySQL is (as of March 2014) the world's second most widely used open-source relational database management system (RDBMS). It is named after co-founder Michael Widenius's daughter, My. The SQL phrase stands for Structured Query Language.
|
||||
|
||||
MySQL is a popular choice of database for use in web applications, and is a central component of the widely used LAMP open source web application software stack (and other 'AMP' stacks). LAMP is an acronym for "Linux, Apache, MySQL, Perl/PHP/Python." Free-software-open source projects that require a full-featured database management system often use MySQL.
|
||||
|
||||
> [wikipedia.org/wiki/MySQL](https://en.wikipedia.org/wiki/MySQL)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a mysql instance
|
||||
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql
|
||||
|
||||
This image includes `EXPOSE 3306` (the mysql port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-mysql:mysql -d application-that-uses-mysql
|
||||
|
||||
## ... or via `mysql`
|
||||
docker run -it --link some-mysql:mysql --rm mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/mysql/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,47 @@
|
||||
# What is Nginx?
|
||||
|
||||
Nginx (pronounced "engine-x") is an open source reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, as well as a load balancer, HTTP cache, and a web server (origin server). The nginx project started with a strong focus on high concurrency, high performance and low memory usage. It is licensed under the 2-clause BSD-like license and it runs on Linux, BSD variants, Mac OS X, Solaris, AIX, HP-UX, as well as on other *nix flavors. It also has a proof of concept port for Microsoft Windows.
|
||||
|
||||
> [wikipedia.org/wiki/Nginx](https://en.wikipedia.org/wiki/Nginx)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## hosting some simple static content
|
||||
|
||||
docker run --name some-nginx -v /some/content:/usr/local/nginx/html:ro -d nginx
|
||||
|
||||
Alternatively, a simple `Dockerfile` can be used to generate a new image that includes the necessary content (which is a much cleaner solution than the bind mount above):
|
||||
|
||||
FROM nginx
|
||||
ADD static-html-directory /usr/local/nginx/html
|
||||
|
||||
Place this file in the same directory as your directory of content ("static-html-directory"), run `docker build -t some-content-nginx .`, then start your container:
|
||||
|
||||
docker run --name some-nginx -d some-content-nginx
|
||||
|
||||
## exposing the port
|
||||
|
||||
docker run --name some-nginx -d -p 8080:80 some-content-nginx
|
||||
|
||||
Then you can hit `http://localhost:8080` or `http://host-ip:8080` in your browser.
|
||||
|
||||
## complex configuration
|
||||
|
||||
docker run --name some-nginx -v /some/nginx.conf:/etc/nginx.conf:ro -d nginx
|
||||
|
||||
For information on the syntax of the Nginx configuration files, see [the official documentation](http://nginx.org/en/docs/) (specifically the [Beginner's Guide](http://nginx.org/en/docs/beginners_guide.html#conf_structure)).
|
||||
|
||||
Be sure to include `daemon off;` in your custom configuration to ensure that Nginx stays in the foreground so that Docker can track the process properly (otherwise your container will stop immediately after starting)!
|
||||
|
||||
If you wish to adapt the default configuration, use something like the following to copy it from a running Nginx container:
|
||||
|
||||
docker cp some-nginx:/etc/nginx.conf /some/nginx.conf
|
||||
|
||||
As above, this can also be accomplished more cleanly using a simple `Dockerfile`:
|
||||
|
||||
FROM nginx
|
||||
ADD nginx.conf /etc/nginx.conf
|
||||
|
||||
Then, build with `docker build -t some-custom-nginx .` and run:
|
||||
|
||||
docker run --name some-nginx -d some-custom-nginx
|
||||
@@ -0,0 +1 @@
|
||||
Official build of Nginx.
|
||||
@@ -0,0 +1,73 @@
|
||||
# What is Nginx?
|
||||
|
||||
Nginx (pronounced "engine-x") is an open source reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, as well as a load balancer, HTTP cache, and a web server (origin server). The nginx project started with a strong focus on high concurrency, high performance and low memory usage. It is licensed under the 2-clause BSD-like license and it runs on Linux, BSD variants, Mac OS X, Solaris, AIX, HP-UX, as well as on other *nix flavors. It also has a proof of concept port for Microsoft Windows.
|
||||
|
||||
> [wikipedia.org/wiki/Nginx](https://en.wikipedia.org/wiki/Nginx)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## hosting some simple static content
|
||||
|
||||
docker run --name some-nginx -v /some/content:/usr/local/nginx/html:ro -d nginx
|
||||
|
||||
Alternatively, a simple `Dockerfile` can be used to generate a new image that includes the necessary content (which is a much cleaner solution than the bind mount above):
|
||||
|
||||
FROM nginx
|
||||
ADD static-html-directory /usr/local/nginx/html
|
||||
|
||||
Place this file in the same directory as your directory of content ("static-html-directory"), run `docker build -t some-content-nginx .`, then start your container:
|
||||
|
||||
docker run --name some-nginx -d some-content-nginx
|
||||
|
||||
## exposing the port
|
||||
|
||||
docker run --name some-nginx -d -p 8080:80 some-content-nginx
|
||||
|
||||
Then you can hit `http://localhost:8080` or `http://host-ip:8080` in your browser.
|
||||
|
||||
## complex configuration
|
||||
|
||||
docker run --name some-nginx -v /some/nginx.conf:/etc/nginx.conf:ro -d nginx
|
||||
|
||||
For information on the syntax of the Nginx configuration files, see [the official documentation](http://nginx.org/en/docs/) (specifically the [Beginner's Guide](http://nginx.org/en/docs/beginners_guide.html#conf_structure)).
|
||||
|
||||
Be sure to include `daemon off;` in your custom configuration to ensure that Nginx stays in the foreground so that Docker can track the process properly (otherwise your container will stop immediately after starting)!
|
||||
|
||||
If you wish to adapt the default configuration, use something like the following to copy it from a running Nginx container:
|
||||
|
||||
docker cp some-nginx:/etc/nginx.conf /some/nginx.conf
|
||||
|
||||
As above, this can also be accomplished more cleanly using a simple `Dockerfile`:
|
||||
|
||||
FROM nginx
|
||||
ADD nginx.conf /etc/nginx.conf
|
||||
|
||||
Then, build with `docker build -t some-custom-nginx .` and run:
|
||||
|
||||
docker run --name some-nginx -d some-custom-nginx
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/nginx/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,24 @@
|
||||
# What is Node.js?
|
||||
Node.js is a software platform for scalable server-side and networking applications. Node.js applications are written in JavaScript, and can be run within the Node.js runtime on Mac OS X, Windows and Linux with no changes.
|
||||
|
||||
Node.js applications are designed to maximize throughput and efficiency, using non-blocking I/O and asynchronous events. Node.js applications run single-threaded, although Node.js uses multiple threads for file and network events. Node.js is commonly used for real time applications due to its asynchronous nature.
|
||||
|
||||
Node.js internally uses the Google V8 JavaScript engine to execute code, and a large percentage of the basic modules are written in JavaScript. Node.js contains a built-in asynchronous I/O library for file, socket and HTTP communication. The HTTP and socket support allows Node.js to act as a web server without additional web server software such as Apache.
|
||||
|
||||
> [wikipedia.org/wiki/Node.js](https://en.wikipedia.org/wiki/Node.js)
|
||||
|
||||
# How to use this image
|
||||
|
||||
FROM node
|
||||
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
|
||||
# install your application's dependencies
|
||||
RUN npm install
|
||||
|
||||
# replace this with your application's default port
|
||||
EXPOSE 8888
|
||||
|
||||
# replace this with your main "server" script file
|
||||
CMD [ "node", "server.js" ]
|
||||
@@ -0,0 +1 @@
|
||||
The Official Build of Node.js. Node.js is a platform for scalable server-side and networking applications.
|
||||
@@ -0,0 +1,50 @@
|
||||
# What is Node.js?
|
||||
Node.js is a software platform for scalable server-side and networking applications. Node.js applications are written in JavaScript, and can be run within the Node.js runtime on Mac OS X, Windows and Linux with no changes.
|
||||
|
||||
Node.js applications are designed to maximize throughput and efficiency, using non-blocking I/O and asynchronous events. Node.js applications run single-threaded, although Node.js uses multiple threads for file and network events. Node.js is commonly used for real time applications due to its asynchronous nature.
|
||||
|
||||
Node.js internally uses the Google V8 JavaScript engine to execute code, and a large percentage of the basic modules are written in JavaScript. Node.js contains a built-in asynchronous I/O library for file, socket and HTTP communication. The HTTP and socket support allows Node.js to act as a web server without additional web server software such as Apache.
|
||||
|
||||
> [wikipedia.org/wiki/Node.js](https://en.wikipedia.org/wiki/Node.js)
|
||||
|
||||
# How to use this image
|
||||
|
||||
FROM node
|
||||
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
|
||||
# install your application's dependencies
|
||||
RUN npm install
|
||||
|
||||
# replace this with your application's default port
|
||||
EXPOSE 8888
|
||||
|
||||
# replace this with your main "server" script file
|
||||
CMD [ "node", "server.js" ]
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/node/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/perl/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,25 @@
|
||||
# What is Python
|
||||
Python is a widely used general-purpose, high-level programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than would be possible in languages such as C. The language provides constructs intended to enable clear programs on both a small and large scale.
|
||||
|
||||
> [wikipedia.org/wiki/Python_(programming_language)](https://en.wikipedia.org/wiki/Python_(programming_language))
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your python app project
|
||||
FROM python:3
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
CMD ["python3", "./your-daemon-or-script.py"]
|
||||
|
||||
or (if you need caveman Python):
|
||||
|
||||
FROM python:2
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
CMD ["python2", "./your-daemon-or-script.py"]
|
||||
|
||||
## 2. build the python app image
|
||||
docker build -t my-python-app .
|
||||
|
||||
## 3. start the python app container
|
||||
docker run -it --name some-python-app my-python-app
|
||||
@@ -0,0 +1 @@
|
||||
Python is a widely used general-purpose, high-level programming language.
|
||||
@@ -0,0 +1,51 @@
|
||||
# What is Python
|
||||
Python is a widely used general-purpose, high-level programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than would be possible in languages such as C. The language provides constructs intended to enable clear programs on both a small and large scale.
|
||||
|
||||
> [wikipedia.org/wiki/Python_(programming_language)](https://en.wikipedia.org/wiki/Python_(programming_language))
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your python app project
|
||||
FROM python:3
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
CMD ["python3", "./your-daemon-or-script.py"]
|
||||
|
||||
or (if you need caveman Python):
|
||||
|
||||
FROM python:2
|
||||
ADD . /usr/src/app
|
||||
WORKDIR /usr/src/app
|
||||
CMD ["python2", "./your-daemon-or-script.py"]
|
||||
|
||||
## 2. build the python app image
|
||||
docker build -t my-python-app .
|
||||
|
||||
## 3. start the python app container
|
||||
docker run -it --name some-python-app my-python-app
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/python/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,29 @@
|
||||
# What is Ruby on Rails
|
||||
|
||||
Ruby on Rails, often simply referred to as Rails, is an open source web application framework which runs via the Ruby programming language. It is a full-stack framework: it allows creating pages and applications that gather information from the web server, talk to or query the database, and render templates out of the box. As a result, Rails features a routing system that is independent of the web server.
|
||||
|
||||
> [wikipedia.org/wiki/Ruby_on_Rails](https://en.wikipedia.org/wiki/Ruby_on_Rails)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your rails app project
|
||||
|
||||
FROM rails
|
||||
|
||||
Put this file in the root of your app, next to the `Gemfile`.
|
||||
|
||||
This image includes multiple `ONBUILD` triggers so that should be all that you need for most applications. The build will `ADD . /usr/src/app`, `RUN bundle install`, `EXPOSE 3000`, and set the default command to `rails server`.
|
||||
|
||||
## 2. build the rails app image
|
||||
|
||||
docker build -t my-rails-app .
|
||||
|
||||
## 3. start the rails app container
|
||||
|
||||
docker run --name some-rails-app -d my-rails-app
|
||||
|
||||
Then hit `http://container-ip:3000` in a browser. On the other hand, if you need access outside the host on port 8080:
|
||||
|
||||
docker run --name some-rails-app -p 8080:3000 -d my-rails-app
|
||||
|
||||
Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser.
|
||||
@@ -0,0 +1 @@
|
||||
Ruby On Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
|
||||
@@ -0,0 +1,55 @@
|
||||
# What is Ruby on Rails
|
||||
|
||||
Ruby on Rails, often simply referred to as Rails, is an open source web application framework which runs via the Ruby programming language. It is a full-stack framework: it allows creating pages and applications that gather information from the web server, talk to or query the database, and render templates out of the box. As a result, Rails features a routing system that is independent of the web server.
|
||||
|
||||
> [wikipedia.org/wiki/Ruby_on_Rails](https://en.wikipedia.org/wiki/Ruby_on_Rails)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your rails app project
|
||||
|
||||
FROM rails
|
||||
|
||||
Put this file in the root of your app, next to the `Gemfile`.
|
||||
|
||||
This image includes multiple `ONBUILD` triggers so that should be all that you need for most applications. The build will `ADD . /usr/src/app`, `RUN bundle install`, `EXPOSE 3000`, and set the default command to `rails server`.
|
||||
|
||||
## 2. build the rails app image
|
||||
|
||||
docker build -t my-rails-app .
|
||||
|
||||
## 3. start the rails app container
|
||||
|
||||
docker run --name some-rails-app -d my-rails-app
|
||||
|
||||
Then hit `http://container-ip:3000` in a browser. On the other hand, if you need access outside the host on port 8080:
|
||||
|
||||
docker run --name some-rails-app -p 8080:3000 -d my-rails-app
|
||||
|
||||
Then hit `http://localhost:8080` or `http://host-ip:8080` in a browser.
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/rails/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,25 @@
|
||||
# What is Redis?
|
||||
Redis is an open-source, networked, in-memory, key-value data store with optional durability. It is written in ANSI C. The development of Redis has been sponsored by Pivotal since May 2013; before that, it was sponsored by VMware. According to the monthly ranking by DB-Engines.com, Redis is the most popular key-value store. The name Redis means REmote DIctionary Server.
|
||||
|
||||
> [wikipedia.org/wiki/Redis](https://en.wikipedia.org/wiki/Redis)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a redis instance
|
||||
docker run --name some-redis -d redis
|
||||
|
||||
This image includes `EXPOSE 6379` (the redis port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## start with persistent storage
|
||||
|
||||
docker run --name some-redis -d redis redis-server --appendonly yes
|
||||
|
||||
If persistence is enabled, data is stored in the `VOLUME /data`, which can be used with `--volumes-from some-volume-container` or `-v /docker/host/dir:/data` (see [docs.docker volumes](http://docs.docker.com/userguide/dockervolumes/)).
|
||||
|
||||
For more about Redis Persistence, see [http://redis.io/topics/persistence](http://redis.io/topics/persistence).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-redis:redis -d application-that-uses-redis
|
||||
|
||||
## ... or via `redis-cli`
|
||||
docker run -it --link some-redis:redis --rm redis sh -c 'exec redis-cli -h "$REDIS_PORT_6379_TCP_ADDR" -p "$REDIS_PORT_6379_TCP_PORT"'
|
||||
@@ -0,0 +1 @@
|
||||
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
|
||||
@@ -0,0 +1,51 @@
|
||||
# What is Redis?
|
||||
Redis is an open-source, networked, in-memory, key-value data store with optional durability. It is written in ANSI C. The development of Redis has been sponsored by Pivotal since May 2013; before that, it was sponsored by VMware. According to the monthly ranking by DB-Engines.com, Redis is the most popular key-value store. The name Redis means REmote DIctionary Server.
|
||||
|
||||
> [wikipedia.org/wiki/Redis](https://en.wikipedia.org/wiki/Redis)
|
||||
|
||||
# How to use this image
|
||||
|
||||
## start a redis instance
|
||||
docker run --name some-redis -d redis
|
||||
|
||||
This image includes `EXPOSE 6379` (the redis port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
|
||||
|
||||
## start with persistent storage
|
||||
|
||||
docker run --name some-redis -d redis redis-server --appendonly yes
|
||||
|
||||
If persistence is enabled, data is stored in the `VOLUME /data`, which can be used with `--volumes-from some-volume-container` or `-v /docker/host/dir:/data` (see [docs.docker volumes](http://docs.docker.com/userguide/dockervolumes/)).
|
||||
|
||||
For more about Redis Persistence, see [http://redis.io/topics/persistence](http://redis.io/topics/persistence).
|
||||
|
||||
## connect to it from an application
|
||||
docker run --name some-app --link some-redis:redis -d application-that-uses-redis
|
||||
|
||||
## ... or via `redis-cli`
|
||||
docker run -it --link some-redis:redis --rm redis sh -c 'exec redis-cli -h "$REDIS_PORT_6379_TCP_ADDR" -p "$REDIS_PORT_6379_TCP_PORT"'
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/redis/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,22 @@
|
||||
# What is Ruby
|
||||
Ruby is a dynamic, reflective, object-oriented, general-purpose programming language. It was designed and developed in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan.
|
||||
|
||||
According to its authors, Ruby was influenced by Perl, Smalltalk, Eiffel, Ada, and Lisp. It supports multiple programming paradigms, including functional, object-oriented, and imperative. It also has a dynamic type system and automatic memory management.
|
||||
|
||||
> [wikipedia.org/wiki/Ruby_(programming_language)](https://en.wikipedia.org/wiki/Ruby_(programming_language))
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your ruby app project
|
||||
FROM ruby
|
||||
CMD ["./your-daemon-or-script.rb"]
|
||||
|
||||
Put this file in the root of your app, next to the `Gemfile`.
|
||||
|
||||
This image includes multiple `ONBUILD` triggers so that should be all that you need to bootstrap most applications. The build will `ADD . /usr/src/app` and `RUN bundle install`.
|
||||
|
||||
## 2. build the ruby app image
|
||||
docker build -t my-ruby-app .
|
||||
|
||||
## 3. start the ruby app container
|
||||
docker run -it --name some-ruby-app my-ruby-app
|
||||
@@ -0,0 +1 @@
|
||||
Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.
|
||||
@@ -0,0 +1,48 @@
|
||||
# What is Ruby
|
||||
Ruby is a dynamic, reflective, object-oriented, general-purpose programming language. It was designed and developed in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan.
|
||||
|
||||
According to its authors, Ruby was influenced by Perl, Smalltalk, Eiffel, Ada, and Lisp. It supports multiple programming paradigms, including functional, object-oriented, and imperative. It also has a dynamic type system and automatic memory management.
|
||||
|
||||
> [wikipedia.org/wiki/Ruby_(programming_language)](https://en.wikipedia.org/wiki/Ruby_(programming_language))
|
||||
|
||||
# How to use this image
|
||||
|
||||
## 1. create a `Dockerfile` in your ruby app project
|
||||
FROM ruby
|
||||
CMD ["./your-daemon-or-script.rb"]
|
||||
|
||||
Put this file in the root of your app, next to the `Gemfile`.
|
||||
|
||||
This image includes multiple `ONBUILD` triggers so that should be all that you need to bootstrap most applications. The build will `ADD . /usr/src/app` and `RUN bundle install`.
|
||||
|
||||
## 2. build the ruby app image
|
||||
docker build -t my-ruby-app .
|
||||
|
||||
## 3. start the ruby app container
|
||||
docker run -it --name some-ruby-app my-ruby-app
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ruby/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,76 @@
|
||||
**Built with [Stackbrew](https://github.com/dotcloud/stackbrew/) from [github.com/dotcloud/stackbrew/blob/master/library/ubuntu](https://github.com/dotcloud/stackbrew/blob/master/library/ubuntu)**
|
||||
|
||||
As of April 18 2014 these images are based on the official Ubuntu Minimal packages. They are pretty barebones. See the links under 'installed packages' to find which packages are installed.
|
||||
|
||||
----------
|
||||
|
||||
$ docker images ubuntu
|
||||
REPOSITORY TAG IMAGE ID
|
||||
ubuntu 10.04 3db9c44f4520
|
||||
ubuntu 12.04 1edb91fcb5b5
|
||||
ubuntu 12.10 0232356d9a18
|
||||
ubuntu 13.04 2e68994ad893
|
||||
ubuntu 13.10 9d076f5398dd
|
||||
ubuntu 14.04 c1bd2f6276a1
|
||||
ubuntu latest c1bd2f6276a1
|
||||
ubuntu lucid 3db9c44f4520
|
||||
ubuntu precise 1edb91fcb5b5
|
||||
ubuntu quantal 0232356d9a18
|
||||
ubuntu raring 2e68994ad893
|
||||
ubuntu saucy 9d076f5398dd
|
||||
ubuntu trusty c1bd2f6276a1
|
||||
|
||||
## sources.list
|
||||
|
||||
$ docker run ubuntu:14.04 grep -v '^#' /etc/apt/sources.list
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty universe
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates universe
|
||||
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-security universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security universe
|
||||
|
||||
-
|
||||
|
||||
$ docker run ubuntu:12.04 cat /etc/apt/sources.list
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-updates main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-updates main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise universe
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-updates universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-updates universe
|
||||
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-security main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-security main restricted
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-security universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-security universe
|
||||
|
||||
## Issues
|
||||
|
||||
If you run into any problems with this image, please check (and potentially file new) [issues on the tianon/docker-brew-ubuntu-core repo](https://github.com/tianon/docker-brew-ubuntu-core/issues), which is the source for this image.
|
||||
|
||||
## Installed packages
|
||||
|
||||
* [lucid (10.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [precise (12.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [quantal (12.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [raring (13.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [saucy (13.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [trusty (14.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
@@ -0,0 +1 @@
|
||||
Official Ubuntu base image
|
||||
@@ -0,0 +1,102 @@
|
||||
**Built with [Stackbrew](https://github.com/dotcloud/stackbrew/) from [github.com/dotcloud/stackbrew/blob/master/library/ubuntu](https://github.com/dotcloud/stackbrew/blob/master/library/ubuntu)**
|
||||
|
||||
As of April 18 2014 these images are based on the official Ubuntu Minimal packages. They are pretty barebones. See the links under 'installed packages' to find which packages are installed.
|
||||
|
||||
----------
|
||||
|
||||
$ docker images ubuntu
|
||||
REPOSITORY TAG IMAGE ID
|
||||
ubuntu 10.04 3db9c44f4520
|
||||
ubuntu 12.04 1edb91fcb5b5
|
||||
ubuntu 12.10 0232356d9a18
|
||||
ubuntu 13.04 2e68994ad893
|
||||
ubuntu 13.10 9d076f5398dd
|
||||
ubuntu 14.04 c1bd2f6276a1
|
||||
ubuntu latest c1bd2f6276a1
|
||||
ubuntu lucid 3db9c44f4520
|
||||
ubuntu precise 1edb91fcb5b5
|
||||
ubuntu quantal 0232356d9a18
|
||||
ubuntu raring 2e68994ad893
|
||||
ubuntu saucy 9d076f5398dd
|
||||
ubuntu trusty c1bd2f6276a1
|
||||
|
||||
## sources.list
|
||||
|
||||
$ docker run ubuntu:14.04 grep -v '^#' /etc/apt/sources.list
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty universe
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates universe
|
||||
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
|
||||
deb http://archive.ubuntu.com/ubuntu/ trusty-security universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security universe
|
||||
|
||||
-
|
||||
|
||||
$ docker run ubuntu:12.04 cat /etc/apt/sources.list
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-updates main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-updates main restricted
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise universe
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-updates universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-updates universe
|
||||
|
||||
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-security main restricted
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-security main restricted
|
||||
deb http://archive.ubuntu.com/ubuntu/ precise-security universe
|
||||
deb-src http://archive.ubuntu.com/ubuntu/ precise-security universe
|
||||
|
||||
## Issues
|
||||
|
||||
If you run into any problems with this image, please check (and potentially file new) [issues on the tianon/docker-brew-ubuntu-core repo](https://github.com/tianon/docker-brew-ubuntu-core/issues), which is the source for this image.
|
||||
|
||||
## Installed packages
|
||||
|
||||
* [lucid (10.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [precise (12.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [quantal (12.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [raring (13.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [saucy (13.10) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
* [trusty (14.04) minimal](http://packages.ubuntu.com/trusty/ubuntu-minimal)
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/ubuntu/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
@@ -0,0 +1,23 @@
|
||||
# What is WordPress?
|
||||
WordPress is a free and open source blogging tool and a content management system (CMS) based on PHP and MySQL, which runs on a web hosting service. Features include a plugin architecture and a template system. WordPress is used by more than 22.0% of the top 10 million websites as of August 2013. WordPress is the most popular blogging system in use on the Web, at more than 60 million websites. The most popular languages used are English, Spanish and Bahasa Indonesia.
|
||||
|
||||
> [wikipedia.org/wiki/WordPress](https://en.wikipedia.org/wiki/WordPress)
|
||||
|
||||
# How to use this image
|
||||
|
||||
docker run --name some-wordpress --link some-mysql:mysql -d wordpress
|
||||
|
||||
The following environment variables are also honored for configuring your WordPress instance:
|
||||
|
||||
- `-e WORDPRESS_DB_USER=...` (defaults to "root")
|
||||
- `-e WORDPRESS_DB_PASSWORD=...` (defaults to the value of the `MYSQL_ROOT_PASSWORD` environment variable from the linked mysql container)
|
||||
- `-e WORDPRESS_DB_NAME=...` (defaults to "wordpress")
|
||||
- `-e WORDPRESS_AUTH_KEY=...`, `-e WORDPRESS_SECURE_AUTH_KEY=...`, `-e WORDPRESS_LOGGED_IN_KEY=...`, `-e WORDPRESS_NONCE_KEY=...`, `-e WORDPRESS_AUTH_SALT=...`, `-e WORDPRESS_SECURE_AUTH_SALT=...`, `-e WORDPRESS_LOGGED_IN_SALT=...`, `-e WORDPRESS_NONCE_SALT=...` (default to unique random SHA1s)
|
||||
|
||||
If the `WORDPRESS_DB_NAME` specified does not already exist in the given MySQL container, it will be created automatically upon container startup, provided that the `WORDPRESS_DB_USER` specified has the necessary permissions to create it.
|
||||
|
||||
If you'd like to be able to access the instance from the host without the container's IP, standard port mappings can be used:
|
||||
|
||||
docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d wordpress
|
||||
|
||||
Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser.
|
||||
@@ -0,0 +1 @@
|
||||
WordPress started as just a blogging system, but has evolved to be used as full content management system and so much more through thousands of plugins, widgets, and themes.
|
||||
@@ -0,0 +1,49 @@
|
||||
# What is WordPress?
|
||||
WordPress is a free and open source blogging tool and a content management system (CMS) based on PHP and MySQL, which runs on a web hosting service. Features include a plugin architecture and a template system. WordPress is used by more than 22.0% of the top 10 million websites as of August 2013. WordPress is the most popular blogging system in use on the Web, at more than 60 million websites. The most popular languages used are English, Spanish and Bahasa Indonesia.
|
||||
|
||||
> [wikipedia.org/wiki/WordPress](https://en.wikipedia.org/wiki/WordPress)
|
||||
|
||||
# How to use this image
|
||||
|
||||
docker run --name some-wordpress --link some-mysql:mysql -d wordpress
|
||||
|
||||
The following environment variables are also honored for configuring your WordPress instance:
|
||||
|
||||
- `-e WORDPRESS_DB_USER=...` (defaults to "root")
|
||||
- `-e WORDPRESS_DB_PASSWORD=...` (defaults to the value of the `MYSQL_ROOT_PASSWORD` environment variable from the linked mysql container)
|
||||
- `-e WORDPRESS_DB_NAME=...` (defaults to "wordpress")
|
||||
- `-e WORDPRESS_AUTH_KEY=...`, `-e WORDPRESS_SECURE_AUTH_KEY=...`, `-e WORDPRESS_LOGGED_IN_KEY=...`, `-e WORDPRESS_NONCE_KEY=...`, `-e WORDPRESS_AUTH_SALT=...`, `-e WORDPRESS_SECURE_AUTH_SALT=...`, `-e WORDPRESS_LOGGED_IN_SALT=...`, `-e WORDPRESS_NONCE_SALT=...` (default to unique random SHA1s)
|
||||
|
||||
If the `WORDPRESS_DB_NAME` specified does not already exist in the given MySQL container, it will be created automatically upon container startup, provided that the `WORDPRESS_DB_USER` specified has the necessary permissions to create it.
|
||||
|
||||
If you'd like to be able to access the instance from the host without the container's IP, standard port mappings can be used:
|
||||
|
||||
docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d wordpress
|
||||
|
||||
Then, access it via `http://localhost:8080` or `http://host-ip:8080` in a browser.
|
||||
|
||||
# Issues and Contributing
|
||||
|
||||
We are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
|
||||
|
||||
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
|
||||
|
||||
We recommend discussing your plans through a [GitHub issue](https://github.com/docker-library/wordpress/issues) before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
|
||||
|
||||
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
|
||||
|
||||
## Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch.
|
||||
|
||||
Update this documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness.
|
||||
|
||||
Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.
|
||||
|
||||
Commit messages should start with a capitalized and short summary (max. 50 chars) written in the imperative, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and force push amended commits to your feature branch. Be sure to post a comment after pushing. The changed commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.
|
||||
|
||||
Before the pull request is merged, make sure that you squash your commits into logical units of work using `git rebase -i` and `git push -f`. Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
|
||||
|
||||
Commits that fix or close an issue should include a reference like Closes #XXXX or Fixes #XXXX, which will automatically close the issue when merged.
|
||||
Reference in New Issue
Block a user