twinvilla.blogg.se

1. CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK UPGRADE
2. CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK FULL
3. CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK CODE

We decided to leave OpenSearch without authentication and locked down access to allow only VPC access (no public access). The configuration was challenging as we could not connect to OpenSearch on AWS if master user is being used for authentication.

CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK FULL

We managed to deploy a full (empty) Magento application but faced some issues and open questions that I would like to highlight here : Please follow the HTTPS prerequisites in the repository to activate the HTTPS configuration. This example is provided as a sample that rely on HTTP, which should never be used in production system.

CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK CODE

The configuration was quite simple (please refer to the magento_app_stack.py in the solution code repo). It is a a Fargate service running on an ECS cluster fronted by an application load balancer.

So we decided to go with opensearch 1.2 hoping for a smooth transition (please refer to the magento_es_stack.py in the solution code repo).įor our ECS deployment we use the construct ApplicationLoadBalancedFargateService. Based on this page, we saw that the migration from Elasticsearch to Opensearch seemed “simple”.

CREATING A MAGENTO STORE WITH BITNAMI MAGENTO STACK UPGRADE

Unfortunately only the 7.17.3 was available so we would have had to upgrade our magneto to 2.4.5 - as per Adobe statement in the requirements: “Adobe only supports the combination of system requirements described in the following table.” - which we didn’t want. Magneto 2.4.4 require Elasticsearch 7.16 but as this version is not available on AWS (7.10 is the latest), we look for an on. But because we wanted to keep it simple, we used the 10.4 version of MariaDB (please refer to the magento_db_stack.py in the solution code repo). We were curious about the capabilities (scaling and manageability) offered by the latest Aurora Serverless. It is composed of 3 mains components :Īs explained earlier, we chose to use the same database engine that we have on-prem. You can find the CDK project on this github. As a small team, we didn’t want to introduce a new tooling but focus on reusing the exiting ones. This choice like the one made for ECS was done to leverage the internal knowledge and capabilities. We chose to use AWS CDK to create our infrastructure as code and to build reusable deliverables. There are other components such Redis, Varnish and RabbitMQ which are not mandatory nor covered in this PoC that should be considered for a production workload.

This architecture derived from the mandatory requirements (Database and Search) to setup a Magento 2.4.4 application. We decided to keep the same engine / version as the one we had on our production system- well we didn’t really stick to that and will explain shortly why.ġ/ An application LoadBalancer forwarding the requests to our Magento applicationĢ/ An ECS cluster on Fargate used to deployed our Magento application on 2 availability zonesĢ/ A MariaDB RDS cluster with a multi availability zone configurationģ/ An Opensearch Cluster with an Elasticsearch engine (.not really). We considered using Aurora Serverless for the database and maybe explore the AWS Opensearch service however our goal was to minimize our effort, not to complicate our PoC nor our migration. We decided to build our PoC with an Amazon RDS for MariaDB and Amazon Elasticsearch. Of course, our motto remained the same: “All managed - when possible”. We used the Magento 2.4.4 version as it was the one we had on-premises.įor the dependencies, Magento needed a MariaDB database and an ElasticSearch. We chose to start a PoC using this image instead of building and managing a new one ourselves. How would we manage the lifecycle of our docker images ? should we build them ourselves from scratch and maintain them ? During our research we found a Magento’s docker image provided by Bitnami on the Amazon public registry. With that said, we just had half of the solution. We wanted to capitalize on what was done by our teams and reuse the tooling already tested. In our last posts ( & ), our colleagues explained why they choose Amazon ECS with AWS Fargate as the platform to run their containerized workloads and not Amazon EKS.