我基本上是试图运行一个React js应用程序,该应用程序主要由3个服务组成,即postgres db,API服务器和UI前端(使用nginx服务)。当前该应用程序在开发模式下使用docker-compose可以按预期工作,但是当我尝试使用kubernetes在生产中运行此程序时,我无法访问该应用程序的api服务器(连接被拒绝)。
我已经尝试在api服务器容器中运行命令npm install。
用于API服务器映像的Dockerfile
FROM node:12.4.0-alpine
RUN mkdir -p usr/src/app
WORKDIR /usr/src/app
COPY package.json package.json
RUN npm install sequelize-cli nodemon -g
RUN npm install && npm cache clean --force
WORKDIR /usr/src/app
COPY . .
WORKDIR /usr/src/app
EXPOSE 8000
CMD [ "npm","start" ]
API服务器的package.json
{
"name": "wootz-backend",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node_modules/.bin/nodemon index.js",
"migrate": "node_modules/.bin/sequelize db:migrate --config config/config.json"
},
"author": "",
"license": "ISC",
"dependencies": {
"express": "^4.17.1",
"nodemon": "^1.19.1",
"pg": "^7.11.0",
"sequelize": "^5.8.7",
"sequelize-cli": "^5.4.0"
}
}
API持久性卷一毫升
kind: PersistentVolume
apiVersion: v1
metadata:
name: api-initdb-pv-volume
labels:
type: local
app: api
spec:
storageClassName: manual
capacity:
storage: 1Mi
accessModes:
- ReadOnlyMany
hostPath:
path: "/home/vignesh/page designer kubernetes yamls/api"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: api-initdb-pv-claim-one
labels:
app: api
spec:
storageClassName: manual
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 1Mi
API持久性卷2 yaml
kind: PersistentVolume
apiVersion: v1
metadata:
name: api-initdb-pv-volume-2
labels:
type: local
app: api
spec:
storageClassName: manual
capacity:
storage: 1Mi
accessModes:
- ReadOnlyMany
hostPath:
path: "/home/vignesh/page designer kubernetes yamls/api"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: api-initdb-pv-claim-two
labels:
app: api
spec:
storageClassName: manual
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 1Mi
APIserver.yaml
apiVersion: v1
kind: Service
metadata:
name: apiserver
labels:
app: apiserver
spec:
ports:
- name: apiport
port: 8000
targetPort: 8000
selector:
app: apiserver
tier: backend
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: apiserver
labels:
app: apiserver
spec:
selector:
matchLabels:
app: apiserver
tier: backend
strategy:
type: Recreate
template:
metadata:
labels:
app: apiserver
tier: backend
spec:
containers:
- image: suji165475/vignesh:apifinal
name: apiserver
env:
- name: POSTGRES_PASSWORD
value: password
- name: POSTGRES_USER
value: postgres
- name: POSTGRES_DB
value: wootz
ports:
- containerPort: 8000
name: myport
volumeMounts:
- name: api-persistent-storage-one
mountPath: /usr/src/app
- name: api-persistent-storage-two
mountPath: /usr/src/app/node_modules
volumes:
- name: api-persistent-storage-one
persistentVolumeClaim:
claimName: api-initdb-pv-claim-one
- name: api-persistent-storage-two
persistentVolumeClaim:
claimName: api-initdb-pv-claim-two
当我尝试在api服务器容器内运行命令npm run migration时,出现错误提示-
/ usr / src / app#npm运行migration
wootz-backend@1.0.0迁移/ usr / src / app 续集db:migrate --config config / config.json
无法解析/ usr / src / app中的sequelize软件包 呃!代码ELIFECYCLE 呃! errno 1 呃! wootz-backend@1.0.0迁移:
sequelize db:migrate --config > config/config.json
呃!退出状态1 呃! 呃! wootz-backend@1.0.0迁移脚本失败。
我也尝试在api容器中运行命令npm install --save sequelize,但是这次我遇到了另一个错误,说-
WARN checkPermissions缺少对/ usr / src / app / node_modules / pg的写入权限 WARN pg-pool@2.0.6需要pg @> 5.0的对等方,但未安装。您必须>自己安装对等依赖项。 WARN wootz-backend@1.0.0没有描述 警告wootz-backend@1.0.0没有存储库字段。
错误!路径/ usr / src / app / node_modules / pg 呃!代码ENOENT 呃!埃尔诺-2 呃!系统调用访问 呃! enoent ENOENT:无此类文件或目录,访问>>'/ usr / src / app / node_modules / pg' 呃! enoent这与npm无法找到文件有关。 呃!先天
注意:仅当我使用kubernetes运行它而不是在使用docker-compose的开发模式下运行时,才会发生此问题。因此,应用程序本身不会有问题。
答案 0 :(得分:1)
您的应用程序应内置在您要部署的Docker映像中。
存在一种将本地源代码安装在Docker映像之上以进行本地开发的“模式”。 该模式仅在Kubernetes中不起作用。您不能在已部署的Kubernetes pod上进行“实时”开发。
幸运的是,解决此问题可使Kubernetes YAML减少大约三分之二。您只需彻底删除部署规范中的PersistentVolume
和PersistentVolumeClaim
,以及volumes:
和volumeMounts:
。
对应用程序进行更改时,需要docker build
新映像,并以某种方式导致重新启动部署。 “最佳”方法是使用不同的图像标签并更改部署对象中的标签,这将导致它进行pod的滚动重新启动,并且如果存在严重问题,则可以将其干净地回滚到旧图像。新代码。
(Kubernetes中这种模式有两个技术问题。首先是您不直接控制Pod将在哪个节点上运行,因此您必须手动将源代码复制到每个节点上;这非常多错过了Kubernetes的要点。第二个问题是,普通docker run
将使用图像中的内容填充安装在图像路径上的空卷,但Kubernetes不会,因此使用匿名卷来进行“技巧”使用图像中的node_modules
树[现在它包含非常重要的应用程序数据,并且Docker将永远不会再对其进行更新]实际上不起作用;您只会得到空的node_modules
。)