CentOS 9 (Apple Silicon) PHP Images ready for Beta Testing!

[navarr]

Happy Wednesday, everyone!

The good news today is that the CentOS 9 PHP images are now ready for beta testing. These images support both amd64 and arm64 operating systems - so it's imperative that both are well tested!

Please, please help me test out these images and report any issues with them. Ideally, I'd like to make these the primary images starting March 20th, assuming there are no major issues left unresolved.

How to Test

Two steps must be taken to test out these images. The first, is that you must be using the current in-development version of Warden. To do so, you can either checkout the develop branch if you installed via git, or you can run brew install wardenenv/warden/warden --HEAD to have brew upgrade to the develop version.

After you have done this, you need to add to either your ~/.warden/.env file (recommended) or a project's .env file: WARDEN_NIGHTLY=1. If you have WARDEN_NIGHTLY set, Warden will instead use the -indev images. You can verify this by running warden env config in an environment and checking the image underneath your php services.

How to Report

Please report issues as normal through the Warden New Issue Wizard.

[wigman]

Awesome work @navarr. Just installed an instance and it works well. A lot faster on Mac M2 Max processor than the previous images. If I run into any issues later I'll report here.

[ihor-sviziev]

Also was testing it today - looks like everything works fine!

[Vinai]

After migrating as described above, I get the following error when running warden env up:

 % warden env up
Connecting traefik to mos-hyva-245p1_default network
Connecting tunnel to mos-hyva-245p1_default network
Connecting mailhog to mos-hyva-245p1_default network
ERROR: no such image: docker.io/wardenenv/mariadb:${MARIADB_VERSION:-10.4}: invalid reference format

It looks like bash variable expansion isn't being applied, and the literal string is used as the version.
Any ideas?

[Vinai]

After adding WARDEN_ELASTICHQ=0 to the project .env the container no longer is created.
No more amd64 container warnings 🎉

However, I'm still not able to reindex:

Catalog Search index process error during indexation process:
Could not ping search engine: No alive nodes found in your cluster

[sprankhub]

Just to be sure... You did remove the Elasticsearch volume as described? What does ES cluster health tell you?

[Vinai]

@sprankhub Just to be sure I followed your instructions, I did warden env stop && docker image rm mos-hyva-245p1-elasticsearch-1.
Then I ran docker volume rm mos-hyva-245p1_esdata

After that I did

 % warden env up
Connecting traefik to mos-hyva-245p1_default network
Connecting tunnel to mos-hyva-245p1_default network
Connecting mailhog to mos-hyva-245p1_default network
[+] Running 9/9
 ⠿ Volume "mos-hyva-245p1_esdata"            Created
 ⠿ Container mos-hyva-245p1-elasticsearch-1  Started
 ⠿ Container mos-hyva-245p1-rabbitmq-1       Started
 ⠿ Container mos-hyva-245p1-db-1             Started
 ⠿ Container mos-hyva-245p1-redis-1          Started
 ⠿ Container mos-hyva-245p1-php-fpm-1        Started
 ⠿ Container mos-hyva-245p1-nginx-1          Started
 ⠿ Container mos-hyva-245p1-php-debug-1      Started
 ⠿ Container mos-hyva-245p1-varnish-1        Started
"docker container inspect" requires at least 1 argument.
See 'docker container inspect --help'.

Usage:  docker container inspect [OPTIONS] CONTAINER [CONTAINER...]

Display detailed information on one or more containers

I had not noticed that error earlier, I don't think it was there before.

[Vinai]

After another warden env stop && warden env up the error is gone, synchronization completes.
And finally:

$ bin/magento ind:rein
Design Config Grid index has been rebuilt successfully in 00:00:00
Customer Grid index has been rebuilt successfully in 00:00:00
Category Products index has been rebuilt successfully in 00:00:03
Product Categories index has been rebuilt successfully in 00:00:00
Catalog Rule Product index has been rebuilt successfully in 00:00:00
Product EAV index has been rebuilt successfully in 00:00:00
Inventory index has been rebuilt successfully in 00:00:00
Catalog Product Rule index has been rebuilt successfully in 00:00:00
Stock index has been rebuilt successfully in 00:00:00
Product Price index has been rebuilt successfully in 00:00:00
Catalog Search index has been rebuilt successfully in 00:00:18

My sample data is back ❤️

Thank you all very much for your help: 🙏

[Vinai]

So, to summarize, after migrating from an intel mac, I think these steps where necessary for me:

• switch to docker-compose 2 in the Docker Desktop
• delete the old warden installation in /usr/local/Cellar
• install the new warden version as described at the start of this discussion
• add WARDEN_ELASTICHQ=0 to the project .env
• remove the elasticsearch volume using docker volume rm {{VOLUME_NAME}}
• run warden svc pull && warden env pull before running warden svc up && warden env up
• if there is an error "docker container inspect" requires at least 1 argument., run warden env stop && warden env up
• run warden shell and then reindex with bin/magento index:reindex

[Vinai]

Setting up a new project on silicon, I'm encountering an issue with rabbitmq after the first warden env up

This is my .env

WARDEN_ENV_NAME=hyva-dev
WARDEN_ENV_TYPE=magento2
WARDEN_WEB_ROOT=/

TRAEFIK_DOMAIN=hyva-dev.test
TRAEFIK_SUBDOMAIN=app

WARDEN_DB=1
WARDEN_ELASTICSEARCH=0
WARDEN_OPENSEARCH=1
WARDEN_ELASTICHQ=0
WARDEN_VARNISH=1
WARDEN_RABBITMQ=1
WARDEN_REDIS=1

OPENSEARCH_VERSION=2.5
DB_DISTRIBUTION=mariadb
DB_DISTRIBUTION_VERSION=10.6
NODE_VERSION=18
COMPOSER_VERSION=2
PHP_VERSION=8.1
PHP_XDEBUG_3=1
RABBITMQ_VERSION=3.9
REDIS_VERSION=7.0
VARNISH_VERSION=7.1

WARDEN_SYNC_IGNORE=

WARDEN_ALLURE=0
WARDEN_SELENIUM=0
WARDEN_SELENIUM_DEBUG=0
WARDEN_BLACKFIRE=0
WARDEN_SPLIT_SALES=0
WARDEN_SPLIT_CHECKOUT=0
WARDEN_TEST_DB=0
WARDEN_MAGEPACK=0

BLACKFIRE_CLIENT_ID=
BLACKFIRE_CLIENT_TOKEN=
BLACKFIRE_SERVER_ID=
BLACKFIRE_SERVER_TOKEN=

(the only thing I changed was the node version)

And this is the rabbitmq container log:

2023-03-17 07:34:42 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
2023-03-17 07:38:42 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
2023-03-17 07:40:06 qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[Vinai]

Upping the docker virtual disk size in Docker Desktop to 300G fixed it.

[Vinai]

I'm now running into an issue where the generated/code directory is created with the user belonging to root

www-data@m2-hyva-246-php-fpm:/var/www/html$ ls -ld generated/ generated/code/
drwxr-xr-x 3 www-data www-data 4096 Mar 18 11:42 generated/
drwxrwxr-x 7 root     root     4096 Mar 18 11:42 generated/code/
www-data@m2-hyva-246-php-fpm:/var/www/html$

Trying to run bin/magento setup:upgrade now triggers errors that generated classes can't be found (that is, they can not be written to the directory).

On further inspection I noticed the contents of generated are not synced to the host system. They are only present inside the php-fpm container.

[Vinai]

Restarting the container helped.
While doing though I noticed this message when running warden svc up:

% warden svc up
WARN[0000] Found orphan containers ([portainer]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

Is this a problem that requires some action?

[ihor-sviziev]

This warning appears because you've disabled portainer container, but it wasn't removed, to do so you can run warden svc up --remove-orphans

[Vinai]

Thank you @ihor-sviziev 👍
Currently I think I now have a fully functional migrated project as well as a new project. I'm very happy :)

[navarr]

Beta Testing is now closed.

Please see https://github.com/orgs/wardenenv/discussions/620