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
Related
I have a web part that uses the pageContext to get info about the page that the user is viewing. Until now I hve been available to test the webpart in my private environment by installing it in the app cataloge and then adding it to the page that I want get the info from.
Now is time to test the app in the live environment but since it uses the pageContext it can not be tested in the workbench and I don't want to install it just for testing.
Is there a way to test this app in a similar way like using workbench?
It is a Sharepoint online modern design environment.
Best regards
Americo
If you want to test SPFx projects with site contexts, pageContext, access to lists, etc., the best option is the Hosted Workbench https://your-sharepoint-site-url/_layouts/workbench.aspx (source # Step #6). This should give you at least mockups of the page context, so you ensure all your page context calls are working.
Have you considered a site collection app catalog? If you perhaps have a private site collection on the live environment, the tenant admin can enable a site-collection-scoped app catalog, so anything you install there will not be visible to anyone else in your live environment.
Other than those, I do not believe there is any other way of testing an SPFx web part without uploading/installing the package.
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 use Deis Workflow, which is an open source Platform as a Service (PaaS) that makes it easy to deploy and manage applications on our servers.
I understand twelve-factor is the main guideline for Deis Workflow, but is it possible to use it to create services like Postgres, Redis or MySQL?
Some other PaaS services e.g. Dokku and Flynn allow users to create services and link them to the app containers.
Is there a way to acheive the same result in Deis Workflow?
I'm an engineer at Deis, formerly from the Workflow team, and still occasionally involved in it. Great question. As it seems you already caught on to, Workflow is (currently) hyper-focused on 12factor applications. Generally, what we have said is that anyone wishing to do anything more complex than that may wish to "fall back" on "plain Kubernetes," but that doesn't have to be as painful as it might sound when you take Helm into account. Helm is the Kubernetes package manager (and is another Deis product). Helm 2 just went GA today, in fact. It's easy to create your own Helm charts (packages), but even better than that, many charts already exist for common things like Postgres, Redis, and MySQL (all examples you gave). Hope this helps.
I am Anton - one of the maintainers of Hephy, the open source fork of Deis Workflow. https://github.com/teamhephy
Deis Workflow was originally designed with hyper focus on 12-factor apps and deploying them. We don't see any major changes to that in the coming few months except the possibility to define multiple services per application namespaces. See this PR: https://github.com/teamhephy/controller/pull/71
Aside from all of this, we hope to integrate other services that provide DBaaS (Databases as a Service) and do some blog posts on how to use Hephy Workflow and those services together for a common solution.
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