I'd like to use the ELK stack to visualize data from jhipster similar to the jhipster console that was supported in pre V7 jhipster. Is it still possible to use ELK stack with the newer versions of jhipster or can I install old versions of jhipster and use those?
Related
I have a Node 12 app and am trying to assess when i should migrate up to a newer version of Node. Even though it is no longer officialy suppported the app builds today on v12. I read in heroku's documentation (https://devcenter.heroku.com/articles/nodejs-support) that I can install "most node versions". That seems to explain why the app is still building, but then I also read that official buildpack support is given to active or LTS node versions.
Given the above, what is the implication for older apps? That it will build until a breaking change in the buildpack stops it from building? Is there a buildpack per node version which, if true, would mean that the build will work but without benefit of updates or bugfixes?
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
Can anyone demonstrate on how I can bundle them together and play nicely? I would like to use all the new cool features of node7 and typescript2.0.
And one more question how do I use it in enterprise project?
Just install nodejs 7 globally. Then use Angular CLI which is already using TypeScript 2.x.
Starting with AWS-Lambda and the Serverless Framework i am confused about node versions:
The AWS help site says that (on 21-March-2016)
AWS Lambda supports the following runtime versions:
Node.js: v0.10.36
So i did install Node.js v0.10.36 on my local machine. Installing the latest (v 0.4.2) serverless framework via
npm install serverless -g
it gives the following warning:
npm WARN engine serverless#0.4.2: wanted: {"node":">=4.0"} (current:
{"node":"0.10.36","npm":"1.4.28"})
I thought having the same version locally as on AWS might help having a consistent development environment... Am i wrong? What Node.js version should i run locally to get the most out of serverless?
The Serverless Framework requires Node.js v4.0 or higher. Any version of Node.js within the v4.x or v5.x lines should work.
You are correct that AWS Lambda currently only supports Node.js v0.10.36. The decision to build the Serverless Framework on Node.js v4.0 was done in anticipation that AWS Lamabda would eventually support Node.js v4.0 or higher.
When developing code for AWS Lambda, you should continue to only use features compatible with Node.js v0.10.36. If you make any contributions to the framework, you can use Node.js features available in v4.0+.
Another option is to use Babelify to transform your ES2015 code uploading to AWS Lambda. This allows you to develop in ES2015 without having to wait for AWS Lambda to officially support it. This can be done automatically each time you deploy with the Serverless Framework using the Optimizer Plugin.
Update: A new option now exists, the Serverless Babel Runtime. This goes one step beyond what Optimizer does, and uses Babel inside the runtime itself.
Update 2: AWS Lambda now supports Node.js v4.3.
If you are starting out with a brand new, fresh project I would highly avoid starting with node 0.10.x. That version is just receiving important security fixes at this point, and only for another five months (until October 2016).
The Node.js has adopted the common Long Term Support (LTS) pattern to keep releases timely and stable. Here is the current LTS plan for node.
I would highly recommend starting out with version 4 or 5, depending on your appetite for change and keeping your project up to date. You will be able to take advantage of numerous new features over the 0.10/0.12 releases as well as better prepare you for ES6.
I am currently working on a project in Orchard. We are looking to wrap up an existing .NET MVC Web application within an Orchard Module. Currently, we are having issues with AutoFac.
The original site was built using AutoFac 3.5, however the latest stable version of Orchard is still running on 3.0. The application requires features introduced in 3.3. If I install 3.0 into the module, the features do not work, if I have 3.5 in the module, it produces a conflict.
Can anybody suggest a way of handling this conflict? Or, is it safe to upgrade AutoFac 3.0 in Orchard and if so how should I perform this without breaking it?
Thanks,
If I may suggest, Orchard 1.9 should be released soon™ and it already has dependency on latest stable Autofac 3.5.2. If you don't want to wait you can grab latest repository from GitHub
https://github.com/OrchardCMS/Orchard/tree/1.9-int
It's perfectly stable in my opinion and I find released 1.8.1 to be much more buggy :D.
Copy the web.config file runtime Node from Existing Module (Lucene or Markdown or like) and add the runtime node on conflicts Module Web.Config file. After Compile then clear the Conflict