[Ansible 2.12] Build an Ansible execution environment for CentOS 6 using Docker in WSL2
table of contents
Hello everyone.
He is a member of the System Solutions Department and has recently been attacked by stomach pains and chills that make him unable to sleep, and he has lost his physical strength.
This article is about how to ``build an Ansible execution environment for operating CentOS 6 environment using Docker in WSL2''.
Migration of old environments such as the CentOS 6 environment is strongly recommended, but due to various reasons some may remain.
The current version of Ansible is basically not compatible with these environments.
Therefore, we have prepared an easy-to-use procedure for building an environment for an older version using Docker.
While explaining the premise, we will explain and explain the steps step by step.
Preface
- We do not recommend operating on CentOS 6.
This is only an emergency response to CentOS 6, which exists for unavoidable reasons - You are using a version that is no longer supported.
This is also for emergency use and is not intended to be recommended.
Execution environment
■ Linux environment
OS: AlmaLinux release 8.5 (WSL2 environment)
Shell: Bash
Docker: 26.1.0, build 9714adc■ Windows environment
OS: Windows11 Pro (version: 23H2)
Language setting: Changed to Japanese■ CentOS 6 environment (Vagrant + VirtualBox)
OS: CentOS 6.9 (bento / centos-6.9)
Vagrant: 2.4.1
VirtualBox: 7.0.18 r162988 (Qt5.15.2)
IP: 192.168.33.15
Explanation of the premise
Q.Why do I need a separate Ansible environment for CentOS 6 environment?
A. Newer versions of Ansible (2.13 or later) no longer support CentOS 6's standard Python 2.6, so playbooks can no longer be loaded.
Q.Why Docker inside WSL2?
A. The main Ansible environment used is AlmaLinux 8 (WSL2), and it is easier to run it within it, including managing playbooks.
Q.Is it Docker instead of pyenv?
A. Summary: Docker is more convenient and easier from my standpoint.
- (Since it is not used frequently) If you use Python version control, it will be troublesome to rebuild when migrating to a PC.
- Dockerfile can be used by other people to create the same environment and is more reusable.
- As an infrastructure engineer, it is better to use Docker than Python version control.
funto gain knowledge- (From my psychological point of view) Even if you forget what you put in, it's very easy to do something by looking at the Dockerfile.
Q.Why Ansible-core 2.12?
A. 2.12 is the latest minor version of managed node Python compatible with 2.6.
*If you really want to run Python 2.7 or 3.7 on the control node, please use Python 2.11.
Construction steps
1. WSL2 preparation
Since this is not the main topic of this article, I will briefly explain it.
Enable "Virtual Machine Platform" under "Windows Features".
Then, install ``Windows Subsystem for Linux'' and ``AlmaLinux 8 WSL'' in the Microsoft Store.
You can use it by starting "AlmaLinux 8 WSL" and setting the user name and password for the first startup.
2. Docker preparation
First, install Docker.
#dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo #dnf install docker-ce #systemctl start docker #systemctl enabled docker #docker --version Docker version 26.1.0, build 9714adc *In the case of the author's environment
3. Create Dockefile
Decide on a directory to work in and create a Dockerfile there.
I am working with the location /home/AlmaLinux/docker-study/, but please feel free to configure it as you like.
# Image specification FROM almalinux:8.9 # Change timescale to Japan time RUN ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime # Install required packages RUN dnf -y install \ python38 \ python38-devel \ sshpass \ openssh-clients \ && rm -rf /var/cache/dnf/* \ && dnf clean all # Install Ansible2.12 RUN pip3 --no-cache-dir install ansible-core==2.12.10 # Bind mount destination Specified & automatically created # & Default destination when accessing container WORKDIR /work
FROM almalinux:8.9
It matches the distribution and major version used by WSL2.
RUN ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
It is set to Japan time.
When leaving logs, etc., if the time is left in UTC, it will be out of sync and it will be troublesome, so I would like to set the time for the time being.
RUN dnf -y install \
Things in the Appstream repository of AlmaLinux 8, python3.8 (3.9 is also fine)
And, since sshpass and openssh-client may not be included in the image related to ssh, install them.
&& rm -rf /var/cache/dnf/* \
Delete the dnf(≒yum) cache to reduce the size of the Docker image.
It seems that the dnf clean all command described below may not delete it, so first delete it manually.
&& dnf clean all
Delete the dnf(≒yum) cache to reduce the size of the Docker image.
Why "&&" instead of "RUN"?
To reduce the size of Docker images.
Each time a RUN is executed, the capacity increases as more layers are added in the Docker image.
Therefore, we will reduce the capacity by grouping the parts that can be grouped together in one RUN.
RUN pip3 --no-cache-dir install ansible-core==2.12.10
Since the format has changed from Ansible 2.10 or later to 2.9 or earlier, specify "ansible-core" for the lightweight main body part.
Among them, specify 2.12.10, which is the latest release of 2.12.
If you want to reuse a playbook that you have been using for a long time, it is better to specify "ansible==2.9.27 (or the version you have been using for a long time)" for compatibility.
*If the version is too old, you will be required to use Python 2 series or 3.8 or earlier, so you will need to make adjustments.
Supplement: About Collection
Since "ansible-core" has a minimal configuration, only the basic Collection (ansible.builtin) can be used.
If you want to use many modules while using "ansible-core 2.12.10", specify "ansible==5.10.0", a community package that includes "ansible-core 2.12.10" and module relationships. That's fine.
However, the image size will be larger.
Also, if you are writing to install the Collection required by the playbook, I think there is no problem with just "ansible-core".
Collection relationships and version support are complicated, so this article uses only the basic "ansible-core".
WORKDIR /work
This specifies the working directory in the Dockerfile.
This time, we are specifying the destination directory for bind mounting.
If you specify WORKDIR, it will be created automatically without mkdir (Linux side command), reducing the amount of description.
The configuration also persists when you enter the container, so you can start working directly from the bind mount.
4. docker build
Create an image from a Dockerfile.
#docker build -t ansible2.12:v1 -f Dockerfile . #docker images REPOSITORY TAG IMAGE ID CREATED SIZE ansible2.12 v1 58f4663b655b 14 seconds ago 286MB
I was able to successfully create an image with the repository name "ansible2.12" and the tag name "v1".
5. docker run (bind mount)
The author is writing playbooks etc. by linking WSL2 and VScode.
Therefore, prepare a directory called work for Ansible 2.12 work and bind-mount it as a shared directory.
#cd /home/username/docker-study *Verification directory where author's work is placed #docker run -it --name Ansible2.12 --mount type=bind,src=./work,dst=/work ansible2 .12:v1
I wrote the relative path src=./work for publishing the blog, so please execute the above in the location where the "work" directory is located.
There is no problem with writing an absolute path, so feel free to do as you like.
6. Start execution environment
Let's run it.
#docker run -it --name Ansible2.12 --mount type=bind,src=./work,dst=/work ansible2.12:v1 [root@cf3c2fa0c4d8 work]#
At the same time as execution, I connected to the container with the "-it" option.
WORKDIR is also enabled and has been moved to "/work".
7. Ping test
As a quick test to see if there are any issues with Ansible, let's use the ping module from ansible-core's standard collection (ansible.builtin).
[root@cf3c2fa0c4d8 work]# ansible -m ping -i hosts targetnode [DEPRECATION WARNING]: ansible-core 2.13 will require Python 2.7 or newer on the target. Current version: 2.6.6 (r266:84292, Aug 18 2016, 15 :13:37) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]. This feature will be removed in version 2.13. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. targetnode | SUCCESS = > { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python" }, "changed": false, "ping": "pong" }
There is a warning, but since the target (managed node) is CentOS 6 (Python 2.6), it
is only notified that "You can only use Python 2.7 or later from ansible-core 2.13 (warning)", so it is not a problem. there is no.
The ping successfully arrived in the CentOS 6 environment for verification.
Completion
This completes the process.
After that, just place the playbook and Inventory and you can start working.
I will write Ansible articles for CentOS 6 in the next articles.
lastly
I tried to run it easily with Ansible in a CentOS 6 environment, but I can't run it with the current version.
The reason for this article is to prepare in advance in order to avoid the pain of having to end up doing it manually because building a dedicated environment and verifying it is a hassle.
I used Docker because I thought it was the quickest way to do it, but it's still easy and convenient. (I'll close my eyes on the operational side.)
I hope to use it even more in the future in my infrastructure engineering work.
I hope this article provides some useful knowledge/information to those who read it.
Thank you for reading this far.
Reference materials
Releases and maintenance | Ansible official
https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html
Dockerfile reference — Docker-docs-ja 24.0 documentation
https://docs.docker.jp/engine/reference/builder.htm l
Using bind mounts | Docker documentation
https://docs.docker.jp/storage/bind-mounts.html
Layers — Docker-docs-ja 24.0 documentation | Docker documentation
https://docs.docker.jp/build/guide/layers.html
For cloud/server design and construction
(Click here for service page)