.NET跨平台之旅:生产环境中第2个跑在Linux上的ASP.NET Core站点

今天我们在生产环境中上线了第2个跑在Linux上的ASP.NET Core站点。这是一个简单的Web API站点,通过命令行的方式调用安装在Linux服务器上的程序完成操作。之前用的是nodejs,现在换成了ASP.NET Core,主要代码如下:

var psi = new ProcessStartInfo(command, arguments)
{
    RedirectStandardOutput = true,
    RedirectStandardInput = true,
    CreateNoWindow = true,
    UseShellExecute = false
};

using (var process = Process.Start(psi))
{
    Request.Body.CopyTo(process.StandardInput.BaseStream);
    process.StandardInput.Dispose();
    return process.StandardOutput.ReadToEnd();
}

部署方式与第1个跑在Linux上的ASP.NET Core站点一样,详见 .NET跨平台之旅:在生产环境中上线第一个运行于Linux上的ASP.NET Core站点

时间: 2024-10-12 08:41:07

.NET跨平台之旅:生产环境中第2个跑在Linux上的ASP.NET Core站点的相关文章

.NET跨平台之旅:在生产环境中上线第一个运行于Linux上的ASP.NET Core站点

2016年7月10日,我们在生产环境中上线了第一个运行于Linux上的ASP.NET Core站点,这是一个简单的提供后端服务的ASP.NET Core Web API站点. 项目是在Windows上用V2015开发的,以self-contained应用部署方式发布到Linux服务器.Linux服务器用的是Ubuntu 14.04,站点通过supervisor以服务方式运行,部署在2台阿里云服务器上,用了1台阿里云内网负载均衡. 虽然是很简单的站点,虽然是很小的一步,但是进入生产环境就意味着对性

生产环境中CentOS7部署NET Core应用程序

NET Core应用程序部署至生产环境中(CentOS7) 阅读目录 环境说明 准备你的ASP.NET Core应用程序 安装CentOS7 安装.NET Core SDK for CentOS7. 部署ASP.NET Core应用程序 配置Nginx 配置守护服务(Supervisor) 这段时间在使用Rabbit RPC重构公司的一套系统(微信相关),而最近相关检验(逻辑测试.压力测试)已经完成,接近部署至线上生产环境从而捣鼓了ASP.NET Core应用程序在CentOS上的部署方案,今天

生产环境中的PHP WEB 简单架构

使用三台虚拟机器, Ubuntu1(nginx) 192.168.226.128 Ubuntu2(php-fpm+memcached)192.168.226.132 CentOS(MySQL)192.169.226.130 PHP 框架使用CakePHP,这个是很常用的MVC 框架,基于事件的分发模型 当然需要注意的是框架代码要部署在php-fpm机器上,需要在nginx 中配置的配置如下 余下的内容: 1. CakePHP 框架代码 2. PHP 内核 3. Nginx内核 4. 数据库设计模

[virtualenv]生产环境中使用virtualenv

virtualenv 对于python开发和部署都是好工具,可以隔离多个python版本和第三方库的版本,这里作者总结了几个常用python服务怎么样结合virtual部署 原文链接 Python 中我最喜欢的东西之一就是可以使用 virtualenv 去创建隔离的环境.非常简单的就可以在不同的项目中部署不同的python类库. 有一个比较棘手的问题就是在生产环境中使用virtualenv 部署几个不同的服务有一些配置上的不同. 于是我就从我的项目中收集了几种不同的服务的不同配置方式. 可以肯定

理解Docker(6):若干企业生产环境中的容器网络方案

本系列文章将介绍 Docker的相关知识: (1)Docker 安装及基本用法 (2)Docker 镜像 (3)Docker 容器的隔离性 - 使用 Linux namespace 隔离容器的运行环境 (4)Docker 容器的隔离性 - 使用 cgroups 限制容器使用的资源 (5)Docker 网络 (6)若干企业生产环境中的容器网络方案 Docker 在早期只有单机上的网络解决方案,在 1.19 版本引入了原生的 overlay 网络解决方案,但是它的性能损耗较大,可能无法适应一些生产环

生产环境中使用脚本实现tomcat start|status|stop|restart

一.在实际生产环境中tomcat启动是在bin目录下采用自带脚本startup.sh启动:使用shutdown.sh关闭.如下图: 再如果对于新手来讲在不知道路径情况下重启是一件头痛的事情(注意没有reload,所以重启只能shutdown.sh在startup.sh):而且这里还有一个坑等着: 什么坑呢?   如图: tomcat服务是启动成功了的.那么我想停止服务用shutdown.sh,会出现什么呢? 进程还在而且成为了僵尸进程,万恶啊?居然关不了,终极方法kill -9 进程号.试试?

生产环境中tomcat的配置

生产环境中要以daemon方式运行tomcat 通常在开发环境中,我们使用$CATALINA_HOME/bin/startup.sh来启动tomcat, 使用$CATALINA_HOME/bin/shutdown.sh来关闭tomcat. 而在生产环境中,我们要配置tomcat使其以daemon方式运行,这是因为: 以daemon运行不受终端影响,不会因为退出终端而停止运行 可以让tomcat以普通用户身份运行,可以让tomcat随linux启动而启动 如何将tomcat配置成守护进程 将tom

在生产环境中安全执行更新删除SQL脚本的技巧

今天在生产环境上解决问题,由于广发银行的管理制度是开发公司是不允许确生产环境的,所以我们只能把要更新的语句发给运营中心,由运营中心的投产人员执行,我们则在旁边看着:在他执行的时候发现了一个很有趣的技巧,现在分享出来. 我们知道每一次在生产环境中执行中执行更新删除语句的时候都要格外小心,要做好数据备份,但是即便这样对于一个做了分库分表设计,有十几个G的库来说更新一句SQL后发现忘记写WHERE语句或是语句写错了,恢复备份的成本都是相当高的. 我注意到运营中心的人在拿到我的SQL语句后,把它放到MS

JDK 9 发布仅数月,为何在生产环境中却频遭嫌弃?

千呼万唤始出来,在经历了整整一年的跳票之后,Java 9 终于在 9 月 21 日拨开云雾,露出真正的面目.对众多 Java 程序员来说,这一天无疑是一个重大的日子,首先 Java 开发者们再也不用羡慕别的自带 REPL 的语言了,不用为了试个 Java 功能而开个 Groovy shell:其次最主要的莫过于 Jigsaw 项目下颠覆性的 Java 模块化了,有了它,自己定制/裁剪 JDK 变得更直接. 其中,整个 Java 的核心内容非 JDK 莫属,其包括了 Java 运行环境(Java