OTDI Web Hosting Migration to Containers

OTDI Web Hosting is migrating how it functions behind-the-scenes to a more modern container-based design. These migrations will occur in various phases to minimize impact to our customers’ websites.

What are containers?


The goal is to decouple the site environments from each other while retaining our existing resource sharing and ease-of-management benefits so that we’re able to continue supporting so many websites with so little overhead. Containers are isolated from one another and cannot interact unless explicitly permitted to. Events on one site will be far less capable of “spilling over” and affecting its neighbors. (i.e. cache flushes, config change restarts, etc.)

In fact, containers are sufficiently isolated that they’re able to run entirely different environments. Along with our legacy Redhat/Apache/PHP design we’ll be able to offer native support for Node.js, Python, Ruby, R, and even modern .NET. This separation also allows the creation of container images customized to individual applications (Drupal, Mediawiki, etc.) wherein large portions have been moved off of the shared NFS storage and onto much faster local storage.

Design Changes

Currently we operate from a cluster of traditional, monolithic web servers where an Apache service hosts individual websites via VirtualHost sections. Web content is shared between servers via NFS and only simple load-balancing is used. (SSL cert management and persistent sessions)

The post-migration design will have websites hosted by individual containers running within a Kubernetes cluster. An ingress controller will perform site routing in place of Apache VirtualHosts. SSL cert & persistent session management will continue to be managed by a similar load balancer; however, it will be linked to a Kubernetes ingress object and therefore also cluster-managed.

What is Kubernetes?

Phase 1 – July 22, 2022

Phase 1 is meant to be almost entirely transparent. Filesystem paths, Apache versions, PHP builds, etc. won’t be changing; however, there is one unavoidable caveat described below. The VirtualHost sections for all PHP-based accounts will be converted to reverse proxies that pass traffic through to the Kubernetes cluster behind it. Sites will continue to see the same Redhat+Apache+PHP environment that they currently do.

There will be one potentially-impactful change, though. After the move, sites will begin to see the remote client’s IP address the usual way rather than needing to extract it from various odd header values such as OITClientSrcIP or X-Forwarded-For. This will affect .htaccess setups or PHP code that was written to accommodate these odd headers. The solution is to modify the site to behave the way it normally should. (i.e. replacing an ACL setup in .htaccess based on SetEnvIf regexps and X-Forwarded-For with the equivalent standard “Require ip” directives)

Phase 2 – TBD

This phase will involve migrating the remaining sites using Phusion Passenger to use native containers for Node.js/Ruby/Python. Once this is complete, DNS changes will be made so that all traffic is routed directly to the Kubernetes cluster and the legacy web server cluster will be decommissioned.

Phase 3 – TBD

Once the infrastructure is fully in place we’ll begin leveraging some of the other benefits that containers provide. Specialized containers for common applications (Drupal, Mediawiki, etc) will be made available where a site’s files are separated into two categories – persistent and ephemeral.

Persistent files are a site’s custom pieces. This includes assets, configuration, custom plugins, upload areas, etc. These will remain on shared NFS storage ensure that the site stays synchronized across all running instances.

Ephemeral files are the common, unchanging pieces of the application itself – its core code, common assets & modules, support scripts, documentation, etc. As this code will be identical across all websites running the application, it can be included in the container image itself. Container storage is local so it’s much faster than NFS and able to be cached more effectively. Since these files make up the majority of each page load, the site runs noticeably faster.

Please feel free to send any additional questions to me at hicks.367@osu.edu.

Need More Information?

Is OSU Web Hosting right for you? Check your eligibility.

More questions? Check the support section or contact us.

Ready to get started? Request hosting now!