The Ortus BlogBox
We are very excited to bring you a new commercial product release for the Ortus Family: Redis Lucee Extension The Redis Lucee Extension allows you to natively connect to a Redis Server cluster and leverage it for distributed caching, session/client storage and distribution, cluster RAM file systems, and much more. It can allow your Lucee servers to scale and extend easily by leveraging Redis Server as the platform of choice for session/cluster managements, caching and virtual file-systems.
If you have ever asked yourself these questions, then our Lucee Extension can help you:
- Want to use round-robin balancing instead of sticky sessions?
- How do you deal with session/client information when you have more than 1 server in your cluster?
- How can I scale my Lucee servers when I am running out of RAM?
- Do you want your users to still be logged in even if a server in my cluster dies or is restarted?
- Do you want to have a cluster-wide file system?
- Do you want to be able to cache data in a distributed and elastic fashion?
We have been working with Redis Server for many years and it has been a true pleasure to not only build scalable farms with it, but also it is incredibly responsive when it comes down to key-value storage and caching transactions.
Here are some of the major features of our Redis Extension:
- Add Native Redis functionality to any Lucee CFML application
- Install at the server level (Available to all contexts)
- Create Cache connections in the Lucee administrator to connect to any network-accessible Redis cluster
- Set and get objects from Redis via standard CFML functions and tags
cachePut(), cacheGet(), <cfcache action="get|put">
- Fully supports all built-in Lucee cache functions including wildcard filters
- Seamlessly distribute storage of the following to any bucket in a Redis cluster
- Lucee session storage
- Lucee client storage
- Lucee RAM resource
- Seamlessly cache the following to any timeout-sensitive bucket in a Redis cluster
- Results of database queries
- Results of deterministic functions
- Complex or simple objects in your application's code
- Cached templates
- Results of database queries
- Registers new CFML Built-In Functions (BIFs) for native Java access to Redis
- Extremely lightweight and fast
Please visit our Extension page for all the necessary resources.
Today we released our 3.8 series of docker images ( current source version
2.1.0 ) which include a number of improvements and enhancements.
- Updates to CommandBox v3.8+
- Adds support for Docker secrets
- Adds casing aliases for environment variables
- Adds new opinionated password security
- Updates to runtime output for clarity
- Changes image for alpine build to prevent CommandBox errors when installing dependencies
On the heels of and in conjunction with the 3.7.0 release of ContentBox, we are pleased to announce the 3.7.0 release of CommandBox ( a happy coincidence that the version numbers of the two are the same! ).
This release provides major updates in security and functionality to the CFConfig module, which may be used to configure CFML servers at runtime. The settings and environment variables, which were previously handled by the bash script used to start the image, are now delegated to CFConfig. You can read more on using environment variables for CFConfig here.
We've been using our CommandBox Docker images for awhile now for multi-tier development and deployment. We've also received a lot of great feedback from the community that has helped to expand the power and flexibility of the those images in orchestrating CFML server environments.
One important aspect of non-development deployments of applications on the CommandBox image, is the need to warm up the server by seeding the CFML engine file system and configuration before the application is deployed in its target environment/tier. Other than the default Lucee 4.5 engine, which is what CommandBox, itself, runs on, any CFML engine specified in your application's
server.json file is downloaded upon server start. Depending on the latency of your Docker environment's connection, this can mean that a bare-bones first run of your application can take minutes to start up, rather than seconds. For obvious reasons, this is not desirable.