Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment.
A few weeks ago I posted an announcement about a JavaScript-based interface for our mg_web WebServer interfacing addon module. mg_web isn't just restricted to use by JavaScript developers though. Many readers will be ObjectScript developers who are more used to using CSP as their web gateway. Some may even have much older legacy WebLink-based applications (and be wondering how to support them given that IRIS does not support WebLink).
It's not clear to me, when using the InterSystems Container Repository, which version is the best / most recent non-preview Community Edition version to use.
I see lots of 2023.2.x versions, a single 2023.3 and 2024.1 version, but also a latest-cd and latest-em (with no explanation as to what cd and em mean).
I assume the trick is to use one of the latest-xx ones? If so, which?
Unfortunately I haven't been able to find any explanatory information anywhere about the nomenclature conventions used.
The Istio Service Mesh is commonly used to monitor communication between services in applications. The "battle-tested" sidecar mode is its most common implementation. It will add a sidecar container to each pod you have in your namespace that has Istio sidecar injection enabled.
I recently had a company-enforced OS upgrade, and ever since going from mac OS 14.x to 15.x, I am currently having issues with SSL in IRIS.
An ARM (M3 pro) machine running OS 15.2, with the latest Docker Desktop (at the time of writing, 4.37.0). The Docker container runs IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2022.1.2 (Build 574_0_22161U). This container has not changed.
If you plan on using the nginx server to front end you IRIS instance (as opposed to the standard apache web gateway install) you will need to add a few configuration options into the CSP.conf file in order for all urls to work. It took me a little bit to figure this out but this seems to be the configuration that works.
https://www.youtube.com/embed/hALbMzols9o [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
Hi there, I'm wondering if anyone has run into an issue with <FILEFULL> when building an image from the ISC image? Specifically what's happening in our build is we are pre-loading our codebase into the image to make deployments faster and setting up source control, etc. When loading our libraries however we get hit with a <FILEFULL>. The resource limits on docker are pretty beefy and when observing resources on both the machine and container level we don't hit any issues. Oddly, this only happens when using the ARM64 version.
In InterSystems IRIS 2024.3 and subsequent IRIS versions, the AutoML component is now delivered as a separate Python package that is installed after installation. Unfortunately, some recent versions of Python packages that AutoML relies on have introduced incompatibilities, and can cause failures when training models (TRAIN MODEL statement). If you see an error mentioning "TypeError" and the keyword argument "fit_params" or "sklearn_tags", read on for a quick fix.
https://www.youtube.com/embed/GUbe6Iwt9T4 [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
I'm discovering IRIS and I need to POC the solution, with a constraint: containerization. I'm used to deploy my apps in a Swarm cluster, and all my bind volumes are written on a GlusterFS volume.
The problem here, when I start my stack, the first log is:
[WARN] ISC_DATA_DIRECTORY is located on a mount of type 'fuse.glusterfs' which is not supported, consider a named volume for '/iris_conf'
When setting up a new web app in iris (iris is in a container) iris complains that a WSGI framework is not installed. I have installed python into the container as well as both flask and django via the python virtual environment (see second screenshot) and the python language server is running
Is this the wrong way to install flask? How do I get the container version to recoginize that flask is installed?
I'm trying to get the python external language server started up in a container I am starting. The container is up and running but I cannot get the python language server to start.
This is the error that is coming back when trying to start the language server. I have tried creating a custom image with that package installed but it still does not work. Is there something specific that needs to be done to to get this working? (FYI, I have the dotnet version working but creating a custom image and installing the dotnet runtimes via a docker file)
Year
Open Exchange app
.png)