阿里云托管k8s上线python项目

本文详细介绍了如何从零开始在阿里云上使用Kubernetes托管Python项目,包括自定义镜像制作、CICD流程设置,以及gitlab、jenkins、Dockerfile、yaml配置等关键步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

阿里云托管k8s上线python项目

官方有原始的python3镜像,这里我不想用,打算自己做一个,
首先可以下载一个初始化的centos镜像

一、制作镜像

docker pull centos  #下载centos最小化
docker run -dit centos /bin/bash     #后台运行容器
docker exec -it a1b93d28dcfc /bin/bash  #进入容器
yum install vim python3  #下载工具看个人选择
docker commit -m "python in the docker" -a "新上镜像" a1b93d28dcfc python_base
docker tag python_base registry.cn-hangzhou.aliyuncs.com/xxxprodk8s/python3:v1 #打包成镜像
docker push registry.cn-hangzhou.aliyuncs.com/xxx/python3:v1 #上传镜像到阿里云

二、CICD

创建gitlab仓库并添加文件
脚本文件 *.py
安装文件 requirements.txt

requirements.txt文件生成方法

pip install pipreqs

进入需要生成文件的目录执行: pipreqs ./
可能会遇见
UnicodeDecodeError: ‘gbk’ codec can’t decode byte 0x80 in position 776: illegal multibyte sequence
解决方法:指定编码格式

pipreqs ./  --encoding=utf8

oss上传文件
可根据环境细分
{build.sh,python.yaml,Dockerfile}

通过jenkins拉取gitlab代码,通过oss工具拉取build脚本生成镜像

build.sh

dates=`date +%Y%m%d-%H%M%S`
tag=`echo $tag |sed 's/\///g'`
registry='registry-vpc.cn-hangzhou.aliyuncs.com/xxxxx'
echo "${tag}-${GIT_COMMIT:0:8}-${dates}" >  ${image}-${dates}.txt
ossutil  -c /etc/oss/ossutilconfig  cp -rf ./${image}-${dates}.txt oss://xxx/xxx-config/python/test/images_version/${image}.txt
image=${registry}/${image}:${tag}
rm -f Dockerfile && ossutil  -c /etc/oss/ossutilconfig  cp oss://xxx/xxx-config/python/Dockerfile ./Dockerfile
docker build  -t ${image} . && \
docker tag ${image} ${image}-${GIT_COMMIT:0:8}-${dates} && \
docker push ${image}-${GIT_COMMIT:0:8}-${dates} && \
docker rmi -f ${image} ${image}-${GIT_COMMIT:0:8}-${dates}

Dockerfile

FROM registry.cn-hangzhou.aliyuncs.com/xxx/python3:v1 
RUN mkdir /app/lib -p
RUN mkdir /home/appuser/logs/ -p
RUN echo "Asia/Shanghai" > /etc/timezone

WORKDIR /app
ADD appFindRedeemCode.py /app/lib/app.py
ADD requirements.txt /app/lib/

RUN pip3 install --no-cache-dir -r /app/lib/requirements.txt -i https://pypi.mirrors.ustc.edu.cn/simple
RUN chmod +w /home/appuser/logs/
CMD ["python3","/app/lib/app.py"]

python.yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ${service-name}-deployment
  labels:
    app: ${service-name}
spec:
  replicas: ${replicas} #副本数
  selector:
    matchLabels:
      app: ${service-name}
  template:
    metadata:
      labels:
        app: ${service-name}
    spec:
      volumes:
        - name: ${service-name}-log
          emptyDir: {}
        - name: tz-config
          hostPath:
            path: /usr/share/zoneinfo/Asia/Shanghai
      containers:
        - name: ${service-name}
          image: imagename #镜像
          imagePullPolicy: Always
          ports:
            - containerPort: ${port} #启动端口
          volumeMounts:
            - name: ${service-name}-log
              mountPath: /home/appuser/logs
            - name: tz-config
              mountPath: /etc/localtime
          livenessProbe:
            failureThreshold: 3
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: ${port} #检查存活端口
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: ${port} #检查存活端口
            timeoutSeconds: 1
          resources: #pod资源限制
            limits:
              cpu: ${cpu}m
              ephemeral-storage: 10Gi
              memory: ${mem}Mi
            requests:
              cpu: ${cpu}m
              ephemeral-storage: 10Gi
              memory: ${mem}Mi
          env:
            - name: "_node_name_"
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: "_node_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
        - name: logtail #阿里云logtail日志收集服务
          image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest
          command:
            - sh
            - -c
            - /usr/local/ilogtail/run_logtail.sh 10
          livenessProbe:
            exec:
              command:
                - /etc/init.d/ilogtaild
                - status
            initialDelaySeconds: 30
            periodSeconds: 30
          resources:
            limits:
              memory: 512Mi
            requests:
              cpu: 10m
              memory: 30Mi
          env:
            - name: "ALIYUN_LOGTAIL_USER_ID"
              value: "xxxxx" #阿里云账号id
            - name: "ALIYUN_LOGTAIL_USER_DEFINED_ID"
              value: "${service-name}-prod"
            - name: "ALIYUN_LOGTAIL_CONFIG"
              value: "/etc/ilogtail/conf/cn-hangzhou/ilogtail_config.json"
            - name: "ALIYUN_LOG_ENV_TAGS"
              value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
            - name: "_pod_name_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: "_pod_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: "_namespace_"
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: "_node_name_"
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: "_node_ip_"
              valueFrom:
                fieldRef:
                  fieldPath: status.hostIP
          volumeMounts:
            - name: ${service-name}-log
              mountPath: /home/appuser/logs
      affinity: #pod可用区亲和度调整
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: topology.kubernetes.io/zone
                  operator: In
                  values:
                    - cn-hangzhou-i
                    - cn-hangzhou-h
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 50
              preference:
                matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                      - cn-hangzhou-i
            - weight: 50
              preference:
                matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                      - cn-hangzhou-h
---
apiVersion: v1
kind: Service #SVC服务
metadata:
  name: ${service-name}-svc
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: ${port}
  selector:
    app: ${service-name}
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig  #日志收集服务
metadata:
  name: ${service-name}-prod-config
spec:
  project: ${logname}
  logstore: ${service-name}-prod-log-stdout
  machineGroups:
    - ${service-name}-prod
  shardCount: 2 
  lifeCycle: 90
  logtailConfig:
    inputType: file
    configName: ${service-name}-prod-config
    inputDetail:
      logType: common_reg_log
      logPath: /home/appuser/logs
      filePattern: '*.log'
      dockerFile: false

整体流程从jenkins–>gitlab–>oss–>cicd流水线工具–>k8s容器发布
细节不过多赘述了

<think>好的,我现在需要帮助用户回答关于是否自己编写ETL程序作为替代AWS DMS的问题。首先,用户之前询问了DMS的费用情况,现在想知道是否有更好的方法,比如自己写ETL程序。我需要比较自建ETL和DMS的优缺点,分析适用场景,并给出建议。 首先,回顾之前的回答,用户可能是在考虑成本优化,或者对DMS的功能有更多需求。用户可能有一定的技术背景,想了解自建的可能性,但不确定投入和回报。需要明确自建ETL的优缺点,尤其是成本、灵活性、维护等方面。 接下来,我需要整理自建ETL的优势,比如成本可控、灵活性高、避免厂商锁定。然后列出缺点,如开发周期长、维护成本高、扩展性挑战等。同时,要对比DMS,说明在哪些情况下自建更合适,比如定制需求高、长期项目、数据规模大等。 还要考虑用户可能没提到的点,例如团队的技术能力、项目时间线、长期维护计划。是否需要推荐混合方案,比如部分使用DMS,部分自建,或者使用其他工具如Airflow、Spark等。 需要确保回答结构清晰,分点列出优缺点、适用场景、技术选型建议,以及何时选择自建ETL。还要注意语言口语化,避免技术术语过多,但保持专业性。最后给出总结建议,帮助用户根据自身情况做决策。</think>以下是关于自建ETL程序与AWS DMS的对比分析及决策建议: --- ### 一、自建ETL vs AWS DMS的核心差异 | **维度** | **自建ETL程序** | **AWS DMS** | |----------------|---------------------------------------|-----------------------------------| | **开发成本** | 需投入开发、测试、文档时间(可能持续数月) | 几乎零开发时间(配置即用) | | **运维成本** | 需团队长期维护(异常处理、版本升级、监控) | AWS全托管(自动修复/扩展) | | **灵活性** | 可完全定制逻辑(如复杂清洗规则、异构数据源适配) | 受限于DMS内置功能,部分场景需绕路实现 | | **可靠性** | 依赖团队技术能力(可能因代码缺陷导致数据丢失) | SLA保障(自动重试/断点续传) | | **隐藏成本** | 服务器成本+人力成本+技术债务 | 实例运行费+数据传输费 | --- ### 二、自建ETL的优势场景(何时值得自己写?) 1. **超复杂数据转换** - *案例*:需要实时解析非结构化日志(如JSON嵌套5层+正则清洗) - *工具建议*:用 **Apache Spark Structured Streaming**(Python/Scala API) 2. **特殊数据源适配** - *场景*:迁移老旧系统(如IBM AS/400数据库) - *方案*:用 **Python+SQLAlchemy** 定制连接器 3. **规避厂商锁定** - *需求*:希望迁移程序能跨云(阿里云/腾讯云/AWS通用) - *框架推荐*:**Apache Airflow** + **Kafka Connect** 4. **长期成本敏感型项目** - *测算*:若数据流水线需运行3年以上,自建可能比DMS节省60%+费用 --- ### 三、自建ETL的典型挑战 1. **开发陷阱** - 时间低估:一个完整的CDC(变更数据捕获)模块需2-3人月开发 - *失败案例*:某团队未处理**微秒级时间戳冲突**,导致数据重复 2. **运维痛点** - 需自建监控体系(如Prometheus+Grafana跟踪延迟/错误率) - 版本升级可能破坏兼容性(如Kafka客户端协议变更) 3. **扩展性瓶颈** - 单机脚本无法应对数据量激增 → 需重构为分布式架构(如Flink集群) --- ### 四、技术选型建议(不同规模场景) #### 1. 小型项目(<10张表,每日同步) - **推荐方案**:Python脚本 + **psycopg2**(PostgreSQL)/ **pymysql** - **示例架构**: ```python # 极简ETL示例(全量同步) import psycopg2 def etl(): # 1. 抽取 src_conn = psycopg2.connect("source_db") data = src_conn.execute("SELECT * FROM table") # 2. 转换(如清洗手机号) cleaned_data = [ (d[0], sanitize_phone(d[1])) for d in data ] # 3. 加载 tgt_conn = psycopg2.connect("target_db") tgt_conn.executemany("INSERT INTO table VALUES (%s, %s)", cleaned_data) ``` #### 2. 中型项目(100+表,准实时同步) - **推荐工具**:**Debezium**(CDC捕获) + **Kafka**(队列) + **Spark**(处理) - **优势**: - Debezium自动解析数据库binlog - Kafka保证至少一次投递 - Spark支持容错处理 #### 3. 大型项目(PB级,企业级数据湖) - **架构选择**: - **批量层**:Airflow调度 **AWS Glue**(Spark集群) - **实时层**:**Flink** on K8s 处理Kafka流 - **元数据**:**Apache Atlas** 管理血缘关系 --- ### 五、何时应坚持用DMS? 1. **缺乏专职数据团队** - DMS开箱即用的CDC、自动类型转换(如Oracle → PostgreSQL)能节省大量调试时间 2. **紧急迁移任务** - *案例*:合规要求3天内完成旧系统下线,无时间开发验证 3. **低频异构迁移** - 如每季度从MongoDB导出一次数据到Redshift,自开发不如DMS任务模板复用方便 --- ### 六、混合方案推荐(平衡成本与灵活性) 1. **核心业务用DMS** - 保障核心交易数据的实时同步可靠性 2. **边缘业务自建ETL** - 用Python脚本处理日志解析等非关键任务 3. **监控统一化** - 将DMS的CloudWatch指标与自建ETL的Prometheus指标整合到同一看板 --- ### 总结决策树 ``` 是否满足以下任一条件? ├── 需要<3个月快速上线 → 选DMS ├── 团队无ETL开发经验 → 选DMS ├── 有长期定制需求+技术储备 → 自建 └── 数据规模超DMS上限(如每秒百万事件)→ 自建+Flink/Kafka ``` 最终建议:**首次迁移用DMS快速验证业务需求,同步用Airflow逐步构建核心表自研流水线**,实现平滑过渡。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值