Currently I am setting name spaces in LENS software manually so that I can see the PODS, Deployment related information easily. Is this setting of namespace can be automated so that this manual work setting namespaces every time whenever adding new cluster to the LENS can be minimized.
LENS : https://k8slens.dev/
Related
Is there a quick way to modify environment variables, or configurations (that is accessible) for a module in IoT Edge?
Once a deployment is created, the environment variables become read only.
What would be the best practice of maintaining a modifiable set of configurations, so I can rather easily change them on the fly, and have the module be able to access them?
On Azure Cloud Services, for example, there are web configurations that are editable and would restart the service so they would kick in (since they are accessible to the service). I am looking for the same kind of behavior.
You can modify the module's device twin in the portal and deploy it. The module should be informed of the update. Alternatively you could send your module a direct message.
Screen shots on how to update the IOT Edge Module's Environment Variables.
Note, I am using the VisionAI Kit camera in this example.
Screen shots on how to update the IOT Edge Module's Environment Variables.
Note, I am using the VisionAI Kit camera in this example.
Your scenario is Cloud To Device (C2D)communication. Refer here for details.
Out of all, the best match is Module Twin Desired Property update.
You can easily create handlers for desired property updates in your edge module implementation and run custom logic based on the changes in desired properties.
For C#, the handler code would go like -
await ioTHubModuleClient.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertiesUpdate, null);
This would be a great read on it.
P.S : Environment Variables are designed to be read-only after deployment. It should only have configurations that are deployment specific and do not change post deployment.
I want to build my own pass platform based on cloudfoundry and openshift. I want to use some of the functions of these two platforms, and I don't want to deploy them all in the environment. Is this feasible? What similar open source projects can learn from?
Let me produce some contents about OpenShift for you as follows.
OpenShift Online : Free plan is enough to your first training.
OpenShift HandsOn training : Awesome practical training, it need not to prepare your env.
OpenShift Documentation - Enterprise and OpenShift OpenSource AKA OKD - Documentation
If you'd like to deploy to your on-premise as open source project of OpenShift, you can review/test/operate the OKD (former name: OpenShift Origin).
I hope if help you. :^)
In regards to Cloud Foundry, it is just a collection of services. We use Bosh to deploy Cloud Foundry, which knows how to deploy all the services so that they can talk to each other & function cohesively. There's nothing that would prevent you from using a different Bosh configuration (or even totally different tool) to deploy these services in a different way.
You can run projects like Gorouter, UAA, Cloud Controller and Garden stand-alone. The individual project sites typically have instructions for doing this.
Ex:
https://github.com/cloudfoundry/gorouter#start
https://github.com/cloudfoundry/uaa#quick-start
Other components might be a little trickier as they depend on each other. Diego, for example, depends on Garden and is built to send logs through Loggregator. In these cases, you might need to do a little work if you didn't want to use one of the dependent components.
https://github.com/cloudfoundry/diego-design-notes#what-are-all-these-repos-and-what-do-they-do
I would disagree with your comment about these systems being bloated, and say that depends on your perspective. If you don't need a lot of the features, then I could see why you might think that. I'd say overkill might be a better way to put it though.
If you don't need all the functionality that PaaS platforms provide, you could look at other options: Dokku, Kubernetes, Knative, etc... You don't get all the features of CF, but the systems have smaller footprints. If you can live without the extra features, then these might be better options for you.
Hope that helps!
I have a generic question here and I have just started using Openshift enterprise and Origin but I would like to know the details on Cloudforms UI, I know that CloudForms UI can do a lot of things including managing Openshift instances but I would like to know the following in terms of managing Openshift instance, can CloudForms be able to do the following :
Order New Openshift environments[For ex, DEV, UAT and PROD], where I could say how many nodes and other details I need for those environments?
Could I be able to plug-in custom tools like ELK/Splunk or AppDynamics to the ordered environments as part of provisioning or later?
Could I be able to populate locally build images and publish it to all the users for using them? For ex: Suppose my middleware teams build images for Tomcat, Nginx etc and they could be able to publish it in CloudForm and I could be able to add them to my newly ordered environments through the Cloudforms UI, could this be done?
Could I add multiple registries and integrate them with my ordered environments.
Does it have all the features that Openshift Enterprise console has? like scanling, S2i etc.
Could I promote my images from one environment to other through the Cloudforms UI?
Can I integrate CI/CD tools and build environments with my ordered environments?
The RBAC in CloudForms can it be modified and catered to suit my requirements/ could this be customized to suit any firms needs?
Could I replicate my DEV openshift ENV to UAT and then to PROD environments? I did see replicators tab in the videos.
Can a charge back model be implemented in the Cloudforms UI ? if its already there then could be customized?
What I am trying to find here is to see if CloudForms can provide an end to end Openshift solution. The end user must only have his/her code ready, rest everything could be within the UI.
Kindly let me know what all are possible and what all are not.
CloudForms is not trying to substitute OpenShift UI, but complement it, giving you more information about the environment and providing additional capabilities on top of OPenShift.
You can see information about what is being done and demos in videos:
https://www.youtube.com/watch?v=FVLo9Nc_10E&list=PLQAAGwo9CYO-4tQsnC6oWgzhPNOykOOMd&index=15
And you can find the presentations here
http://www.slideshare.net/ManageIQ/presentations
Time and again I am faced with the issue of having multiple environments that must be configured individually for an application that would run in all of them (e.g. QA, regional production env's, dev, staging, etc.) and I am wondering what would be the best way to organize different configurations?
Would it be in the database? Different configuration files per environment? Or maybe the same file with different sections/xml tags? How would these be then deployed? Embedded within the app? Or put manually in after installation to be modified in-place?
This question is not technology-specific - I've worked with .net and Java, web-apps and desktop apps and this issue comes up time and again. I'm looking to learn different approaches to maybe adapt a hybrid to address this.
EDIT: There's one caveat that I must point out - when configuration is part of the deployed solution, it is generally installed under root user on the host. In large organizations developers usually don't have a root access to production hosts so any changes to the configuration require a new build and deployment. Needless to say this isn't the nicest approach - especially at organizations that have a very strict release process involving multiple teams and approval levels... (sigh I know!)
Borrowed from Jez Humble and David Farley's book "Continuous Delivery (page 41)", you can:
Your build scripts can pull configuration in and incorporate it into your binaries at build time.
Your packaging software can inject configuration at packaging time, such as when creating assemblies, ears, or gems.
Your deployment scripts or installers can fetch the necessary information or ask the user for it and pass it to your application at
deployment time as part of the installation process.
Your application itself can fetch configuration at startup time or run time.
It is considered bad practice by them to inject configuration files in build and compile times, because you should be able to deploy the same binary file to every environments.
My experience was that you could bake all configuration files for every environments (except sensitive information) to your deployment file (war, jar, zip, etc). And you design your application to take in an extra parameter when starts, to pickup the right sets of configuration files (from your extracted deployment file, or from local/remote file system if they are sensitive, or from a database) during application's startup time.
The question is difficult to answer because it's somewhat vague. There is no technology-agnostic approach to configuration as far as I know. Exactly how configuration is set up will depend on the language/technology in question.
I'm not familiar with .net but with java a popular approach is to have a maven build set up with different profiles. Each profile is specific to an environment. You can then define different properties files that have environment-specific values, an example from the above link is:
environment.properties - This is the default configuration and will be packaged in the artifact by default.
environment.test.properties - This is the variant for the test environment.
environment.prod.properties - This is basically the same as the test variant and will be used in the production environment.
You can then build your project as follows:
mvn -Pprod package
I have good news and bad news.
The good news is that Config4* (of which I am the maintainer) neatly addresses this issue with its support for adaptive configuration. Basically, this is the ability for a configuration file to adapt itself to the environment (including hostname, username, environment variables, and command-line options) in which it is running. Read Chapter 2 of the "Getting Started" manual for details. Don't worry: it is a short chapter.
The bad news is that, currently, Config4* implementations exist only for C++ and Java, so your .Net applications are out of luck. And even with C++ and Java applications, it won't make pragmatic sense to retrofit Config4* into an existing application. Because of this, I'd advise trying to use Config4* only in new applications.
Despite the bad news, I think it is worth your while to read the above-mentioned chapter of the Config4* documentation, because doing so may provide you with ideas that you can adapt to fit your needs.
I am currently trying to use NAnt and CruiseControl.NET to manage various aspects of my software development. Currently, NAnt handles just about everything, including replacing environment specific settings (e.g., database connection strings) based on an input target that I specify on the command line.
CruiseControl.NET is used to build the application for the default environment (dev) anytime new code is committed. I also want CruiseControl.NET to invoke a build for my additional environments test and stage, but I do not want these to be automatically invoked every time that a dev build invoked (daily) as test and stage deployments happen far less frequently. Test and stage deployments only occur when the application is ready for QA.
I can easily do this by specifying multiple projects, one for each environment. However, I already have many projects configured, one for each milestone in within my application. If I have to setup 3 projects for each milestone the CruiseControl.NET configuration can get out of hand quickly.
Here is my question:
Can I parameterize a CruiseControl.NET project configuration such that the parameters are exposed by the web interface?
Preferably (I think), I could have checkboxes for each environment (e.g., dev, test, stage) exposed in the web interface. A build would be made for each environment that is checked, whether the build was forced or automatic. It would be even better if I could default the checked state.
This feature (Dynamic Build Parameters) is currently being worked on for 1.5, and you can try it out in the nightlies. Here's a post describing the feature.
As Scott has mentioned, this isn't available, but it wouldn't take too much just to write a little template and then auto-generate the ccnet.config file given that template and a list of environments in a mail-merge type way.
Unfortunately, you can't do anything like that with CruiseControl.NET. It's a good idea, so you might want to submit it as a feature request.
This is fully supported now starting with cruisecontrol 1.5: http://cruisecontrolnet.org/projects/ccnet/wiki/Parameters