Azure Container Registry
An Azure service that provides a registry of Docker and Open Container Initiative images.
508 questions
@Ravi Sharma
Welcome to Microsoft Q&A Platform, thanks for posting your query here.
I will try and answer your questions.
1. What is the best approach to design WLS on cloud? VMs? AKS? Hybrid? Something else? How to decide?
There are a few different approaches you can take when designing Oracle WebLogic Server on Azure, and the best option for you will depend on your specific requirements and constraints.
Virtual Machines (VMs): Running Oracle WebLogic Server on Azure VMs is a good option if you have existing on-premises workloads that you want to lift and shift to the cloud, or if you need full control over the underlying infrastructure.
Azure Kubernetes Service (AKS): AKS is a managed Kubernetes service that can be used to deploy and scale WebLogic Server in a containerized environment. This approach is useful if you want to leverage the benefits of containerization, such as increased agility and scalability.
Hybrid: You can also consider a hybrid approach, where you run some parts of your WebLogic Server workloads on-premises and other parts on Azure. This can be useful if you have certain regulatory or compliance requirements that prevent you from moving all of your workloads to the cloud.
2. Containers are for the Web logic server? Or the apps using WLS?
Containers can be used for both the Oracle WebLogic Server and the applications that run on it.
Containerizing the WebLogic Server: You can containerize the WebLogic Server itself by packaging it as a Docker image and running it in a container. This approach allows you to easily deploy and scale WebLogic Server instances in a consistent and repeatable manner, and can also help you to achieve higher density and improved resource utilization.
Containerizing the Applications: Additionally, you can containerize the applications that run on WebLogic Server, so that each application runs in its own container. This allows you to isolate the different applications and ensure that they do not interfere with one another, and also enables you to easily move and scale the applications as needed.
When you are containerizing the WebLogic Server you can use the Oracle provided WebLogic Server Docker Images. This images are based on Oracle Linux, include the Oracle JDK, and include an Oracle WebLogic Server installation.
In general, containerizing the WebLogic Server and applications can help you to achieve increased agility, scalability, and security, but it is important to keep in mind that containerization can also add some complexity to your deployment and management process.
3. Where do app configurations reside? Do they have to be on the app containers? Or live on a PV?
When containerizing the applications that run on Oracle WebLogic Server, there are a few different options for where the application configurations can reside.
Within the container: One option is to include the application configurations within the container image itself. This can be useful if you want to ensure that the configuration is always the same, regardless of where the container is running. However, this approach can make it more difficult to update the configuration, as you will need to rebuild and redeploy the container image.
External to the container: Another option is to store the application configurations external to the container. This can be done using a variety of different storage options, such as a shared network file system, a configuration management system, or a volume that is mounted to the container. This approach allows you to more easily update the configuration without having to rebuild and redeploy the container image.
Persistent Volume: Another option is to use a Persistent Volume (PV) to store the application configurations, and mount the PV to the container. This way, if the container is deleted or recreated, the configurations stored in the PV will remain intact.
4. How to update app containers? What happens to app specific customizations/configurations?
There are a few different ways to update application containers that are running on Oracle WebLogic Server in the cloud.
-Rolling updates: One option is to use a rolling update strategy, where you update the containers one at a time, rather than all at once. This allows you to minimize downtime and ensure that the application remains available throughout the update process.
-Blue/green deployment: Another option is to use a blue/green deployment strategy, where you maintain two sets of containers, one for the old version of the application and one for the new version. You can then switch between the two sets of containers, either manually or using an automatic process, to update the application.
-Recreate the container: A third option is to simply recreate the container with the new version of the application. This can be a simpler approach, but it can result in some downtime for the application.
With regards to the application specific customizations and configurations, it depends on how you store them.
If the configurations are stored within the container image, you will need to rebuild and redeploy the container image with the updated configurations.
If the configurations are stored external to the container, you can update the configurations independently of the container and then restart the container.
If you are using PV, the customizations and configurations will remain intact even after the container is deleted or recreated.
It is important to test the updates before deploying them to production, also to have a rollback plan in case something goes wrong. Additionally, you should consider automating the update process as much as possible to make it more efficient and less error-prone.
5. Can Web Logic apps share containers on AKS? Or can they share pods? Or Nodes? Or the AKS cluster? 5.1 Which option is technically feasible? 5.2 Which option is cost effective? 5.3 Which option has lesser operational costs? And efforts?
When deploying Oracle WebLogic Server applications on Azure Kubernetes Service (AKS), there are a few different options for how the applications can share resources.
Sharing containers: It is technically feasible to share containers between different WebLogic Server applications, but it is not recommended. Sharing containers can lead to issues with resource contention and can make it more difficult to isolate and manage the different applications.
Sharing pods: Applications can share pods on AKS, but this is also not recommended as it can lead to the same issues as sharing containers. Each pod should only have one WebLogic Server instance and its corresponding applications.
Sharing nodes: Applications can share nodes on AKS, but it is important to ensure that the node has enough resources to support all of the applications that are running on it. Sharing nodes can lead to issues with resource contention, so it's important to monitor and manage the resources used by each application.
Sharing the AKS cluster: It is technically feasible to share the entire AKS cluster between different WebLogic Server applications, but it is not recommended. Sharing the entire cluster can lead to issues with resource contention, so it is important to carefully monitor and manage the resources used by each application.
In terms of cost-effectiveness, it is generally more cost-effective to isolate the different WebLogic Server applications and not share resources, as this allows you to more easily scale and manage the resources used by each application. In terms of operational costs and efforts, it is less costly and less effortful to isolate the different WebLogic Server applications as it reduces the complexity of managing and monitoring the shared resources.
6. What is the BC-DR process for WLS on cloud?
The process for Business Continuity and Disaster Recovery (BC-DR) for Oracle WebLogic Server on the cloud will depend on the specific architecture and deployment strategy that you are using. However, there are a few key steps that are typically involved in BC-DR for WebLogic Server on the cloud:
-Backup and restore: One important step is to regularly backup your WebLogic Server configuration, application data, and other important information, so that you can restore it in the event of a disaster. This can be done using Azure Backup, Azure Site Recovery, or other backup and recovery solutions.
-High availability: Another important step is to design your WebLogic Server deployment for high availability, so that it can continue to operate even in the event of a disaster. This can be done using Azure Availability Zones, Azure Scale Sets, or other high availability solutions.
-Failover and failback: In the event of a disaster, you will need to be able to failover your WebLogic Server deployment to a secondary location, and then failback to the primary location once it has been restored. This can be done using Azure Site Recovery, or other disaster recovery solutions.
-Testing: Regularly testing your BC-DR process is essential to ensure that it is working as expected and to identify and fix any issues. This can include testing failover and failback procedures, as well as recovery time objective (RTO) and recovery point objective (RPO) testing.
-Monitoring: Monitoring your WebLogic Server deployment and the resources it depends on is important to detect issues and to identify any potential problems before they become critical. This can be done using Azure Monitor, Azure Log Analytics, or other monitoring solutions.
7. How to estimate costs for various options? WLS on Az VMs? WLS on AKS? What all components to consider? Network? Storage? Anything else?
When estimating costs for running Oracle WebLogic Server on Azure, there are a few key components that you should consider:
-Compute: The primary cost component for running WebLogic Server on Azure VMs or AKS will be the compute resources required to run the VMs or the AKS cluster. This will include the cost of the virtual machines or the Kubernetes nodes, as well as any additional compute resources required for high availability or scaling.
-Storage: Another important cost component is storage. If you are running WebLogic Server on Azure VMs, you will need to consider the cost of the virtual hard disks (VHDs) used to store the operating system, WebLogic Server installation, and application data. If you are running WebLogic Server on AKS, you will need to consider the cost of the Kubernetes Persistent Volumes used to store the application data.
-Network: A third cost component is network. You will need to consider the cost of the virtual network, load balancer, and any other networking resources required to connect to the WebLogic Server deployment.
-Licensing: If you are using Oracle WebLogic Server, you will need to consider the cost of the WebLogic Server license.
-Additional services: If you are using additional Azure services, such as Azure Backup, Azure Site Recovery, or Azure Monitor, you will need to consider the cost of those services as well.
It is important to note that costs can vary depending on the resources you are using, the region you are using, and the configuration of your deployment. Additionally, the costs may vary depending on the scale of the deployment.
Azure provides a cost calculator (https://azure.com/cost-calculator) that can help you estimate the costs for different options, also you can use Azure's pricing calculator (https://azure.com/pricing/calculator) to get an estimate for the cost of running WebLogic Server on Azure VMs or AKS, by selecting the resources you expect to use, the region you plan to deploy in, and the duration of the deployment. It is a good idea to monitor your costs and usage regularly to ensure that you are staying within your budget.
8. How to maintain operational activities of WLS on cloud? How much could be automated?
Maintaining the operational activities of Oracle WebLogic Server on the cloud can be done using a variety of different tools and techniques.
-Automation: One important step is to automate as many of the operational activities as possible. This can include tasks such as provisioning new resources, scaling the deployment, and performing backups. Automation can help to reduce errors and increase efficiency.
-Monitoring: Another important step is to monitor the WebLogic Server deployment and the resources it depends on. This can include monitoring the CPU, memory, and storage usage, as well as the availability and performance of the WebLogic Server instances. Monitoring can help to detect issues and identify potential problems before they become critical.
-Logging: Collecting and analyzing the logs from the WebLogic Server instances and the resources it depends on is important to troubleshoot issues and identify patterns that may indicate problems.
-Patching: Keeping the WebLogic Server instances and the underlying infrastructure up-to-date with the latest security patches and updates is important to ensure the security and stability of the deployment.
-Backup and Recovery: Regularly backing up the WebLogic Server instances and the application data is important to ensure that you can recover from a disaster. Having a tested disaster recovery plan in place is crucial.
-Capacity Planning: It is important to monitor the usage of the WebLogic Server instances and the resources it depends on to identify patterns and anticipate the growth of the deployment. This will help you to plan for future scaling and capacity needs.
The exact level of automation that is possible will depend on your specific deployment and use case, but many tasks can be automated using Azure Automation, Azure DevOps, or other automation tools.
Note: It is important to keep in mind to decide on the best approach, you should evaluate your specific use case, and consider factors such as performance, scalability, security, compliance, and cost. If you are not sure which approach is best for your use case, it may be helpful to work with an Azure partner that has experience deploying Oracle WebLogic Server on Azure.
Hope this helps.
If you need further help on this, tag me in a comment.
If the suggested response helped you resolve your issue, please 'Accept as answer', so that it can help others in the community looking for help on similar topics.