What is a Deployment process in back-end development Dealing with Node.js ? And what is the difference between deployment and hosting?
Related
I have WebAPI developed in .NET 6.0 and deployed into AKS. I would like to schedule & run once the API.
What scheduling tools / libraries are available to schedule (run once) the API call other than Azure LogicApp?
Could you share any ideas to achieve this?
There are a couple of options:
1. Hangfire
Hangfire is an open-source library that allows you to schedule jobs in an Asp.Net application. It requires a database or Redis to store the scheduled jobs.
The good thing about Hangfire is that you can build API endpoints in your Asp.Net application to manage the schedule and see the result of the runs.
2. AKS Cronjob
If you don't want to use a database or Redis, you can create an AKS Cronjob, which is managed by AKS.
At work, we use Hangfire but have been considering moving to AKS cronjob as less code to maintain in the application.
Need some suggestions & tips, Please let me know if anyone build the infrastructure on K8s with Oracle Weblogic, DB & SOA (OSB, BIPEL, B2B, BAM).
If anyone build the infrastructure please let me know the benefits & drawbacks. Is it recommended to build it.
Thanks
If you follow best practices; do not install these on Kubernetes. Kubernetes is very good at for micro-services and stateless applications. Of course Kubernetes support stateful applications like cassandra / nodejs ..etc applications you have a chance to deploy applications on Kubernetes using StatefullSets. Kubernetes treats statefull sets different than other resource objects. A StetfullSet Pod is always scheduled on the same machine as long as you do not delete them.Please take a look at the link https://kubernetes.io/docs/tutorials/stateful-application/cassandra/ You can deploy stateful applications on Kubernetes using the link above
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes,-try-it
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
We ran weblogic applications on docker swarm but not on kubernetes. All the configuration on kubernetes for stateful applications is pretty easy compared to docker swarm.
I found that the bottleneck of zipkin is collector and API, are these two components stateless so i can deploy multi collectors and multi API?
I want to deploy zipkin in kubernetes.
Yes, they are both stateless. You can deploy them using whatever horizontal-scalability construct is available to you.
Is there a possibility to deploy only Application Parameters (cloud.xml) somehow without having to redeploy the code or upgrade the application version? For example after deploying the Application on Service fabric cluster, there could be a minor thing I might need to change in one of the parameters in cloud.xml. And it won't make sense to upgrade the version of the Application for this minor change.
I have combed through various sites but did not find anything suitable.
I'd say - no, you can't do this. Here is what Service Fabric application upgrade says on this -
During an upgrade, Service Fabric compares the new application manifest with the previous version and determines which services in the application require updates. Service Fabric compares the version numbers in the service manifests with the version numbers in the previous version. If a service has not changed, that service is not upgraded.
I am setting up an automated deployment environment for a number of decoupled services that are in active development. While I am comfortable with the automated deployment/configuration management aspect, I am looking for strategies on how best to structure the deployment environment to make things a bit easier for developers. Some things to take into consideration:
Developers are generally building web applications, web services, and daemons -- all of which talk to one another over HTTP, sockets, etc.
The developers may not have all running on their locally machine, but still need to be able to quickly do end to end testing by pointing their machine at the environment
My biggest concern with continuous deployment is that we have a large team and I do not want to constantly be restarting services while developers working locally against those remote servers. On the flip side, delaying deployments to this development environment makes integration testing much more difficult.
Can you recommend a strategy that you have used in this situation in the past that was worked well?
Continuous integration doesn't have to mean continuous deployment. You can compile/unit test/etc the code "continuously" thoughout the day without deploying it and only deploy at night. This is often a good idea anyway - to deploy at night or on demand - since people may be integration testing during the day and wouldn't want the codebase to change out from under them.
Consider, how much of the software can developers test locally? If a lot, they shouldn't need the environment constantly. If not a lot, it would be good to set up mocks/stubs so much more can be tested on a local server. Then the deployed environment is only needed for true integration testing and doesn't need to be update constantly throughout the day.
I'd suggest setting up a CI server (Hudson?) and use this to control all deployments to both your QA and production servers. This forces you to automate all aspects of deployment and ensures that the are no ad-hoc restarts of the system by developers.
I'd further suggest that you consider publishing your build output to a repository manager like Nexus , Artifactory or Archiva. In that way deployment scripts could retrieve any version of a previous build. The use of a repository manager would enable your QA team to certify a release prior to it's deployment onto production.
Finally, consider one of the emerging deployment automation tools. Tools like chef, puppet, ControlTier can be used to further version control the configuration of your infrastructure.
I agree with Mark's suggestion in using Hudson for build automation. We have seem successful continuous deployment projects that use Nolio ASAP (http://www.noliosoft.com) to automatically deploy the application once the build is ready. As stated, chef, puppet and the like are good for middle-ware installations and configurations, but when you need to continuously release the new application versions, a platform such as Nolio ASAP, that is application centric, is better suited.
You should have the best IT operation folks create and approve the application release processes, and then provide an interface for the developers to run these processes on approved environments.