Deploy Joomla CMS on Oracle Linux with MySQL Database Service

You can deploy Joomla on Oracle Linux with MySQL Database Service to provide users and enterprises with a scalable and robust architecture, low implementation and maintenance efforts, and access to a large community-led knowledge base.

Joomla, based on the LAMP stack, is one of the most popular content management systems available. Released under the GNU Public License, it is free and open-source, and does not require advanced technical skills to set up and use.

Architecture

You can deploy Joomla in a single-node configuration or as part of a multi-node, highly-available configuration. This reference architecture includes Terraform automation which is compatible with both configurations.

For a production-grade, highly-available architecture, refer to the following diagram, which illustrates a multi-node scenario.

Description of joomla-mds-multi.png follows
Description of the illustration joomla-mds-multi.png

joomla-mds-multi-oracle.zip

The preceding diagram illustrates a simplified high-availability application environment on OCI, with a focus on two virtual machine instances behind a load balancer. These instances exist in two distinct fault domains within an availability domain. This architecture makes use of the OCI File Storage service; Joomla is installed in a shared Network File System (NFS). The file system exists in a dedicated private subnet featuring a Network Security Group (NSG) which allows access to the mount target from all instances.

The following diagram illustrates a simple single-node architecture. It consists of a lightweight deployment, which could be suitable for learning purposes or serve as a proof-of-concept.

Description of joomla-mds-single.png follows
Description of the illustration joomla-mds-single.png

joomla-mds-single-oracle.zip

This single node architecture is an example of a lightweight deployment, which could be suitable for learning purposes or serve as a proof-of-concept. It features a single VM instance and a standalone MySQL DB System. The instance is placed in a public subnet and accessible from the internet, whereas the MySQL DB System is placed in a private subnet. Security Lists and Route Tables are used to restrict and route traffic.

The multi-node architecture contains the following OCI components:
  • Tenancy

    A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization.

  • Policies

    An Oracle Cloud Infrastructure Identity and Access Management policy specifies who can access which resources, and how. Access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access within a specific compartment, or to the tenancy.

  • Compartments

    Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.

  • Virtual cloud network (VCN)

    One of your first steps in OCI is to set up a virtual cloud network (VCN) for your cloud resources. A VCN is a software-defined network that you set up in an OCI region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Load balancer

    The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

  • Compute instances

    Oracle Cloud Infrastructure Compute lets you provision and manage compute hosts. You can launch compute instances with shapes that meet your resource requirements (CPU, memory, network bandwidth, and storage). After creating a compute instance, you can access it securely, restart it, attach and detach volumes, and terminate it when you don't need it.

  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between on-premises networks and VCNs and can also be used to route traffic between VCNs in the same region or across regions.

  • Network security group (NSG)

    NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.

  • File storage

    The Oracle Cloud Infrastructure File Storage service provides a durable, scalable, secure, enterprise-grade network file system. You can connect to a File Storage service file system from any bare metal, virtual machine, or container instance in a VCN. You can also access a file system from outside the VCN by using Oracle Cloud Infrastructure FastConnect and IPSec VPN.

Recommendations

Use the following recommendations as a starting point to for deploying Joomla on Oracle Linux with MySQL Database Service . Your requirements might differ from the architecture described here.
  • VCN

    When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.

    Select an address range that doesn’t overlap with your on-premises network or any other network, so that you can set up a connection between the VCN and your on-premises network, if necessary.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the compute instances within the same tier or role to the same subnet, which can serve as a security boundary.

  • Security

    Use policies to restrict who can access the OCI resources that your company has and how they can access them. Use Vault for additional protection of your keys, certificates and secrets.

    The Networking service offers two virtual firewall features that use security rules to control traffic at the packet level: security lists and network security groups (NSG). An NSG consists of a set of ingress and egress security rules that apply only to a set of VNICs of your choice in a single VCN. For example, you can choose all the compute instances that act as web servers in the web tier of a multi-tier application in your VCN.

    NSG security rules function the same as security list rules. However, for an NSG security rule's source or destination, you can specify an NSG instead of a CIDR block. So, you can easily write security rules to control traffic between two NSGs in the same VCN or traffic within a single NSG. When you create a database system, you can specify one or more NSGs. You can also update an existing database system to use one or more NSGs.

  • Compute

    Pick shapes with the appropriate OCPUs and memory combination, and provision local NVMe and/or block storage according to need, for each instance. Consider using the available flexible shapes, which provide more flexibility in combining OCPUs and memory.

  • Database

    Choose your Oracle MySQL Database Service shape based on the planned workload. Enable MySQL High Availability for three redundant nodes.

Considerations

When deploying Joomla on Oracle Linux with MySQL Database Service, consider these implementation factors:

  • Application availability and scalability

    In this example, in the highly-available architecture, we show two instances in different fault domains within the same availability domain. One could choose to place the instances in different availability domains (in regions where available), for even higher fault tolerance.

    An alternate approach which represents a more dynamic adaptation to more demanding and varying performance needs is the use of an instance pool and autoscaling.

    • Instance pools let you provision and create multiple Compute instances based on the same configuration within the same region.
    • Autoscaling lets you automatically adjust the number of Compute instances in an instance pool based on performance metrics, such as CPU utilization. Autoscaling helps you provide consistent performance for users during periods of high demand and helps you reduce your costs during periods of low demand.
  • Database availability and scalability

    The MySQL Database System displayed in the highly-available architecture makes use of the built-in MySQL High Availability option, which creates three instances and places them in different fault domains.

  • Database backups
    MySQL Database Service supports two types of backup: full backup of all data contained in the database system and incremental backup of only the data that has been added or changed since the last full backup. Backups run in the following ways:
    • Manual: An action in the Console or request made through the API initiates the backup. Manual backups can be retained for a minimum of one day and a maximum of 365 days. Automatic: Automatically scheduled backups run without any required interaction at a time of the user's choosing.
    • Automatic backups are retained for between one and 35 days. The default retention value is seven days. When defined, you can’t edit the retention period of an automatic backup
  • Compute backups

    The Oracle Cloud Infrastructure Block Volumes service lets you make point-in-time backups of data on a block volume. You can then restore these backups to new volumes immediately or later. You can also use the service to make a point-in-time, crash-consistent backup of a boot volume without application interruption or downtime. Boot volume backup capabilities are the same as block volume backup capabilities.

  • Security policies

    Use policies to restrict who can access what OCI resources that your company has and how.

  • Network security

    The Networking service offers two virtual firewall features that use security rules to control traffic at the packet level: security lists and network security groups (NSGs). An NSG consists of a set of ingress and egress security rules that apply only to a set of VNICs of your choice in a single VCN. For example, you can choose all the Compute instances that act as web servers in the web tier of a multitier application in your VCN.

    NSG security rules function the same as security list rules. However, for an NSG security rule's source or destination, you can specify an NSG instead of a CIDR block. So, you can easily write security rules to control traffic between two NSGs in the same VCN or traffic within a single NSG. When you create a database system, you can specify one or more NSGs. You can also update an existing database system to use one or more NSGs.

    In these examples, the instances are displayed as existing in a public subnet. Consider placing them in a private subnet for additional security. In that case, a bastion is required to access the instances.

Deploy

The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.

  • Deploy using the sample stack in Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Select the region where you want to deploy the stack.
    3. Follow the on-screen prompts and instructions to create the stack.
    4. After creating the stack, click Terraform Actions, and select Plan.
    5. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    6. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Acknowledgements

  • Author: Nuno Gonçalves
  • Contributor: Lukasz Feldman