This is the source code of CI&T Solr Docker image(s) hosted at Docker hub.
It contents the source code for building the publicly accessible Docker image(s) and some scripts to easy maintain and update its code.
By utilizing Docker technologies, that already provides an easy way of spinning up new environments along with its dependecies. This image can speed up developers which different backgrounds and equipments to create quickly a new local environment allowing them to easily integrate in automated tests and deployment pipelines.
At this moment we have the following version(s)
Our intent is to be a Docker container that mimics Solr running on Acquia environment with the same version of softwares, packages, modules and its underlying operating system.
Acquia publishes a table with its platform infrastructure information on the link: https://docs.acquia.com/cloud/arch/tech-platform
These images will have the following name pattern: acquia-YYYY-MM-DD
These are the currently software versions bundled in the image(s) by tag.
- acquia-latest OR acquia-2016-11-30
- Ubuntu 12.04.5
- Solr 3.5.0
- Drupal Search API 7.x-1.8
- Dumb-init 1.2.0
Deprecated
- acquia-2016-11-08
- Ubuntu 12.04.5
- Solr 3.5.0
- Drupal Search API 7.x-1.8
- Dumb-init 1.2.0
Since Docker at the moment was designed to run natively just on Linux, we do consider this as premisse.
And also, before proceeding please check the required packages below:
- docker engine => 1.12
- make
- grep
- curl
Clone the desired project code version
DESIRED_VERSION="acquia-latest"
git clone \
--branch "${DESIRED_VERSION}" \
git@github.com:ciandt-dev/docker-hub-solr.git
Build, run and test
make
It is possible to perform any of the actions described below:
make build
make run
make test
make debug
make shell
make clean
make clean-all
make all
or simply
make
As this little framework was designed to be re-utilized on other Docker images it contains a .env file provided at repository root. This file has some self-described variables and they are used by all scripts to perform its own tasks, just inspect the .env file to check them out.
The only one that is important to mention is:
ENVIRONMENT
Environment default value is always local. It is possible to change to any desired string value, this is just an ordinary alias to load one of the configuration files that can exist in conf folder.
Example, if you change it to:
ENVIRONMENT="dev"
When you run (not build) the container will load variables from:
conf/$APP_NAME.dev.env
This is an easy way to inject variables when developing a new script and testing multi-environment solution.
This process will execute instructions in Dockerfile that is inside app folder. Dockerfile will have several environment variables for the build step, when you need to modify them please look for any line starting with ENV. More information about Dockerfile ENV (environment variables) is available at this link.
As described in .env file section, run will load environment variables from an existing file inside conf folder. This approach is better describe in official Docker docs in the link.
Wheter there is a need of debuging or inspecting inside the container there are two options to help:
make debug
and
make shell
The first one runs the container and attaches stderr and stdout to current terminal and prints relevant information.
Second one runs the container and connects to its shell (bash). So, you can inspect files, configurations and the whole container environment.
After any modification we strongly recommend to run tests against the container to check if everything is running smoothly.
This can be done with the command:
make test
These are simple tests at the moment, therefore, very usefull.
Now that you already read the previous steps, you are aware of each function. Knowing that, the easisest way of wrapping up everything together is to just run:
make
This command will build, run and test your recently created container.
Since Docker generates tons of layers that can fast outgrow your hard drive. After that you have finished any modification we encourage to clean up your environment.
There are two commands for this task:
make clean
It stops the running container, removes it and deletes its Docker image. This particular one is very usefull when you are performing changes and you need to rebuild your container many times to check for modifications. In addition, you can combine with make shell for instance, like in this example:
make clean && make shell
And the second one is:
make clean-all
Actually, this one calls make clean first, and then removes Docker dangling images and volumes. More information about dangling images/volumes can be found at this link.
If you have problems, bugs, issues with or questions about this, please reach us in Github issues page.
Needless to say, please do a little research before posting.
We gladly invite you to contribute fixes, new features, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can.
Before you start to code, we recommend discussing your plans through a GitHub issue, especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing.
There are two parts of the documentation.
First, in the master branch, is this README.MD. It explains how this little scripts framework work and it is published on Github page.
Second, in each image version there is an additional README.MD file that explains how to use that specific Docker image version itself. Latest version is always the one seen on Docker Hub page.
We strongly encourage reading both!
Happy coding, enjoy!!
"We develop people before we develop software" - Cesar Gon, CEO