I'm trying to install Openwhisk onto Openshift. I've followed the official guide and it worked.
Now the point is that my environment would be a multitenant ecosystem, so let's pretend having two different users (Ux and Uy) who want to run their containers on my openwhisk environment.
I'd like to have the following projects in my openshift:
Core project, that hosts the Openwhisk's Ingress, Controller, Kafka and CouchDB components (maybe also the Invokers?)
UxPRJ project, that hosts only the containers running actions created by Ux (maybe also the Invokers?)
UyPRJ project, that hosts only the containers running actions created by Uy (maybe also the Invokers?)
The following images better explain what I've in mind:
or also:
Is this possible configuration possible?
Looking around, I wasn't able to find anything like that...
Thank you.
The OpenWhisk loadbalancer which assigns functions to invokers does not segregate users in the way you want, but it is possible to do what you want if you modify the loadbalancer. The way it works now is that there is a list of available invokers which form the allowed set of invokers for a function assignment. You could at that point take into consideration a partitioning based on the user and form the allowed set of invokers differently. There are other ways to realize the partitioning you want as well, but all require modification to the OpenWhisk control plane.
Related
I am currently starting to learn and work with JADE for a project at my university. Today I struggled with one terminology in the JADE documentation. It's the word "container". Sorry, if this is a dumb question, but I am a total beginner in this sector.
From the documentation: "1.1 Containers and Platforms
Each running instance of the JADE runtime environment is called a Container as it can contain several agents. The set of active containers is called a Platform. A single special Main container must always be active in a platform and all other containers register with it as soon as they start. It follows that the first container to start in a platform must be a main container while all other containers must be “normal” (i.e. non-main) containers and must “be told” where to find (host and port) their main container (i.e. the main container to register with)."
My questions: Have these JADE containers anything in common with containers I know from Docker, Podman, LXC, and so on? Is there anything happening to encapsulate an application to avoid problems with dependencies or increase security? Anything with process trees, namespace, or something like that? Or is it just a structure to couple multiple agents that has nothing in common with docker and Co? I'm totally lost at this point... Thanks for your help!
Best regards,
Markus
First off, I've been struggling at the same point recently.
From what I've understood (please correct me if I'm wrong) is that the containers are indeed different from what you know from Docker etc.
The JADE container are rather serving as an organizational unit for agents.
You can, for instance, start a container and run several agents in it, which can identify and communicate with each other. Another possibility is, as you already mentioned in your question, to start a main container and attach other non main-containers to it within the same JADE platform.
As a further step, you can also start two main containers on different machines, each runinng a separate platform and connect them as remote platforms (e.g, by using the MTP HTTP extension).
So, basically agents are organized in containers which are again organized in platforms.
Both docker and containerd provide golang clients and provide some interfaces, such as list images, export images or tag images. How can this be done in cri-o?
eg:
github.com/containerd/containerd
and
github.com/docker/docker/client
it seemed logical to me that such an option would be present for such a simple need, searched around and it seems it's a wanted feature but not fulfilled as it seems by these issues 1 2 3. there is some sense to this since crictl was destined to be a debugging to cri-o and not a container management tool.
from personal use, if you prefer switching from docker, podman could be an option for such operations, it's a daemon-less alternative to docker and cri-o, and employs other opensource tools to achieve its goals:
buildah - handles building and manipulating container images
skopeo - registry specific tasks relating to container images handling (probably the first candidate for your use case even by itself)
If you want to stick to the popular CLI commands podman is your guy, if you want to go as minimalist as possible, using skopeo directly could be an option
hope this helps you in your decision-making process ;)
Suppose you have a Schema that is used in a UI-App (e.g. Vue), a Node.js or Springboot Server and has to validate against Databases (e.g. SQL, mongoDB,...), and maybe some Micro-services running on whatever.
How and where do I manage a this JSON-Schema, so that if I have to change the schema for whatever Reason, that every architectural component can handle the new JSON-Schema(s).
Otherwise I need to update the Schema in up to 10 projects so none is incompatible.
Is it really as simple as having a git project full with just JSON-Schemas or do I need specific loaders for each language/environment?
Are there best practices that I am unaware of?
PS: I don't really think I need the automatically synchronized on runtime, so don't really think I need another Microservice to achieve that.
That being said, if a Microservice is the best way to go, then getting a Microservice it is.
If you keep them in a git project, how do you load them? Clone the project each time the app starts? It may work, but I would go with a more flexible approach that should take too much effort to be done:
Build a JSON schema repository accessible via a REST API
When the app starts, it makes a request to grab the schema (latest, or a specific version)
That way you get an uniform (and scalable) way of playing with the schemas. Even if you think about a hot-reload sometime in the future, you can leverage this approach to do that.
Here is an old project in this direction, you may give it a shot to see if it works (or for some inspiration, at least)
I have seen this terms many times on the google code over configuration or configuration over code. I tried on by searching it on google, but still got nothing. Recently i started work it on gulp again the mystery came code over configuration.
Can you please tell me what is both and what is the difference on them?
Since you tagged this with gulp, I'll give you a popular comparision to another tool (Gruunt) to tell the difference.
Grunt’s tasks are configured in a configuration object inside the
Gruntfile, while Gulp’s are coded using a Node style syntax.
taken from here
So basically with configuration you have to give your tool the information it needs to work like it thinks it has to work.
If you focus on code you tell your tool what steps it has to complete directly.
There's quite a bunch of discussion about which one is better. You'll have to have a read and decide what fits your project best.
Code over configuration (followed by gulp) and the opposite configuration over code (followed by grunt) are approaches/principles in software/program development where both gulp and grunt are using for the same thing as automate tasks. The approach refers to developing programs according to typical programming conventions, versus programmer defined configurations. Both approaches has its own context / purpose and not a question of which one is better.
In gulp each tasks are a java-script function, necessarily no configuration involved up-front (although functions can normally take configuration values) and chaining multiple functions together to create a build script. Gulp use node stream. A stream basically continuously flow of data and can be manipulated asynchronously. However in grunt all the tasks are configured in a configuration object in a file and those are run in sequence.
Reference: https://deliciousbrains.com/grunt-vs-gulp-battle-build-tools/
Because you talked about "code" I'll try and give a different perspective.
While answering a question on figuring out IP address from inside of a docker container Docker container IP address from .net project
there are two codes possible
var ipAddress = HttpContext.Request.HttpContext.Connection.LocalIpAddress;
This will give you the IP address at runtime, but, it won't have control over it.
It can also lead to more code in the future to do something with the IP Address. Like feeding a load balancer or the likes.
I'd prefer a configuration over it.
such as
An environment variable with pre-configured IP addresses for each container service. Such as:
WEB_API_1_IP=192.168.0.10
WEB_API_2_IP=192.168.0.11
.
.
.
NETWORK_SUBNET=192.168.0.0/24
a docker-compose that ties the environment variable to IP address of the container. Such as:
version: '3.3'
services:
web_api:
.
.
.
networks:
public_net:
ipv4_address: ${WEB_API_1_IP}
.
and some .net code that links the two and give access within the code.
Host.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.AddEnvironmentVariables();
})
The code that we wrote is about reading through the configuration.
But it gives way better control. Depending on what environment you are running it you could have different environment files.
The subnet the number of machine they are all configured options rather than tricky code which requires more maintenance and is error prone.
I'm trying to get into Docker and using a current project as a learning exercise. It's a fairly basic application that uses Centos 7, Node and MySQL.
My first thought was pull a CentOS 7 image and the images for the others mentioned above.
When I tested out a Node image I realized I might not need a Centos Image but I do need MySQL... Not what the recommended way to combine images for this or even if it is the right route for this project.
Should I start with an OS image and install all the dependencies/services I would need like on any other server or do I run the images together with Docker Compose or something like that?
I tried looking at building WordPress images to see what they were doing but most tutorials just reference a prebuilt image.
I'm sure I could hack something together but I wanted to go the preferred route.
My hope was that I could specify all of these things in a Dockerfile so I could share it easily.
Any direction on this is appreciated. Thanks!
Quoting from the official best practices:
Run only one process per container
In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. If that service depends on another service, make use of container linking.
If you want to run more than one process in a container you will need some kind of supervisor or init system and you will lose some of the features docker provides (logging, automated restarting).
All in all it is more hassle than running a container per process. And the latter is slightly secure as well, as the processes cannot attack other processes that easily.
So in your concrete case you would run one mysql container and one node container (possibly based on node:onbuild) and link mysql to node to let node talk to mysql.