Docker相关：
1. 请描述你在项目中如何使用Docker容器化Java应用的？遇到过哪些挑战？
在项目中，我们使用Docker容器化Java应用时，主要采用多阶段构建：先用Maven镜像编译打包，再用精简JRE镜像运行应用（COPY --from=builder仅复制必要的JAR文件：配置文件（如application.yml），静态资源目录（如/static），启动脚本（如需特殊JVM参数），最终镜像控制在150MB左右，比传统方式节省60%空间。
配置上，我们设置容器资源限制，并为JVM添加-XX:+UseContainerSupport等参数使其适配容器环境。
遇到的问题包括早期JDK版本无法识别容器内存限制（通过升级JDK解决），
以及GC线程分配不当，默认GC线程数按宿主机CPU核数分配造成资源争抢（手动调整线程数匹配容器配额）。
网络方面使用自定义bridge网络解决通信问题，并通过健康检查监控应用状态。这些实践显著提升了部署效率和资源利用率。
2. 如何优化Docker镜像大小？你常用的基础镜像是什么？
我们主要通过多阶段构建来优化镜像大小，先用完整JDK镜像编译代码，再用精简的Alpine系基础镜像（如eclipse-temurin:17-jre-alpine）运行应用，这样能将镜像从600MB压缩到150MB左右。同时配合合并RUN指令减少层数、清理构建缓存、使用.dockerignore排除无关文件等措施。对于Java应用，还可以通过jlink定制仅含必要模块的JRE来进一步缩减20%空间。这些优化使部署速度提升3倍，资源消耗降低40%。
3. 解释Dockerfile中的COPY vs ADD指令区别，以及多阶段构建的实际应用案例
在Dockerfile中，COPY和ADD的主要区别在于：COPY是基础复制指令，行为简单且缓存效率高；而ADD额外支持自动解压压缩文件和URL下载（但后者建议用RUN wget替代）。实际开发中推荐优先使用COPY，仅在需要解压时使用ADD。多阶段构建的典型应用案例是：第一阶段用完整JDK镜像编译代码，第二阶段切换到仅含JRE的精简镜像运行，通过COPY --from传递编译产物，这样可将Java应用镜像从600MB缩减到150MB，既剔除了构建工具又保持了运行环境纯净。
4. 如何解决容器内Java应用时区不一致问题？容器内存限制如何配置？
容器内Java应用时区问题可采用组合方案：在Dockerfile中设置ENV TZ=Asia/Shanghai并安装tzdata，运行时挂载宿主机时区文件-v /etc/localtime:/etc/localtime:ro，同时为Java应用添加-Duser.timezone=Asia/Shanghai参数。内存配置需双重限制：通过docker run -m 2g限制容器总内存，配合JVM参数-Xmx1500m分配75%内存给堆，剩余25%留给系统进程，并启用-XX:+UseContainerSupport实现自动适配。
Docker-Compose相关：
5. 你如何用docker-compose管理微服务依赖？请举例说明网络配置
我们通过docker-compose的depends_on和healthcheck确保服务启动顺序与可用性，比如将数据库配置为judge-service的依赖项，同时使用环境变量集中管理各服务配置。
未进行网络配置可能出现的问题：服务发现失效，端口冲突风险，跨项目污染，DNS解析问题，性能瓶颈，安全隔离缺失；
Docker Compose默认情况下会为项目创建专属bridge网络，服务通过名称自动发现通信。实际应用中，可通过networks配置实现多网络隔离，结合IPAM进行子网划分，让不同服务接入特定网络实现业务隔离。关键要区分HOST_PORT（外部访问）和CONTAINER_PORT（容器间通信）的不同用途，始终使用服务名称而非IP进行服务发现。典型应用场景包括微服务架构中的网络隔离，以及使用overlay（虚拟网络技术）驱动实现跨主机通信等复杂需求
6. 如何实现容器间的服务发现？环境变量和.env文件的使用规范
在Docker环境中，容器间服务发现主要依靠内置DNS系统，同一网络内的容器可以直接用容器名相互访问，避免了硬编码IP的问题，即使容器重启也能自动更新记录保持连接。多网络环境下可以用"容器名.网络名"的格式精确访问。环境变量管理推荐使用docker-compose的environment字段直接定义少量变量，或通过env_file引用.env文件管理大量配置，后者更适合生产环境，但要注意规范命名（如.env.production）并避免提交到代码库。敏感信息应通过Docker Secrets等安全机制传递，限制变量可见范围。这套方案既简化了服务发现，又实现了配置的集中安全管理
7. 在CI/CD流程中，docker-compose.yml文件如何做多环境适配？
在CI/CD流程中实现docker-compose.yml的多环境适配，核心是通过环境变量注入和文件组合两种方式灵活应对不同部署需求。具体做法是在docker-compose.yml中使用变量占位符（如${DB_HOST}）定义环境差异部分，通过.env文件或CI系统环境变量动态注入不同值；同时采用多文件组合策略，将基础配置保留在主文件，环境特有配置拆分到如docker-compose.prod.yml等文件中，部署时用-f参数叠加。实际应用中通常结合这两种方式，用环境变量控制关键参数，并通过自动化脚本按环境加载对应配置，最终实现同一套配置在不同环境中的无缝切换。
Jenkins相关：
8. 你具体通过哪些优化手段实现部署效率提升50%？请用数据说明
9. Jenkins Pipeline中如何处理构建依赖？如何实现构建失败自动回滚？
在Jenkins Pipeline中，我们通过以下策略优化构建依赖管理和回滚机制：
依赖管理优化
采用共享库(用于在多个Pipeline项目中复用公共代码）集中管理公共依赖和可复用代码
建立智能缓存系统对依赖包和构建产物实施分层缓存
通过环境变量统一管理通用配置
构建执行优化
使用分布式构建集群和并行执行策略
当缓存命中率高时显著提升构建速度
可靠回滚机制
在post构建块中定义failure条件触发自动回滚
容器化部署时调用Kubernetes的rollout undo命令
参数化构建支持选择特定历史版本回滚
10. 如何设计Jenkins的权限管理体系？凭证管理的最佳实践
Jenkins权限管理采用RBAC模型，通过Role-based Authorization Strategy插件划分全局、项目和节点三种角色，实现多层级权限控制。权限分配遵循最小权限原则，结合矩阵授权策略精确控制各类操作访问权限，凭证管理则使用Credentials插件加密存储敏感信息，区分系统和个人凭证并设置定期轮换机制，高安全场景可集成外部密钥管理系统。
综合场景：
11. 当容器出现OOM时，你的排查步骤是什么？如何收集容器日志？
当容器出现OOM时，首先用docker stats检查实时内存使用情况，确认是否达到内存限制阈值。同时通过dmesg | grep -i kill或journalctl -k | grep -i oom查看系统日志中OOM Killer的记录。对于Java应用，重点检查JVM参数配置是否合理，特别是-Xmx和-Xms是否适配容器内存限制，建议配置-XX:+HeapDumpOnOutOfMemoryError参数以便自动生成堆转储文件。排查过程中结合docker logs查看容器错误日志，关注内存相关异常，检查是否存在内存泄漏或大对象缓存未释放问题。日志收集方面，可通过docker logs -f实时跟踪日志，使用--since和--tail参数筛选日志，生产环境建议配置json-file或fluentd日志驱动集中存储日志
12. 如何实现蓝绿部署？在K8s和纯Docker环境下的方案差异
蓝绿部署是一种通过维护两个相同生产环境（蓝环境运行旧版本，绿环境运行新版本）实现零停机发布的策略。在Kubernetes中，可以通过创建两个Deployment并修改Service的selector来切换流量，这种方式原生支持且自动化程度高。而在纯Docker环境下，需要手动运行两个容器实例并通过外部负载均衡器（如Nginx）切换流量，更依赖手动操作。两者核心差异在于Kubernetes提供了原生资源对象支持，而Docker方案需要自行搭建基础设施
13. 容器化部署后，如何监控JVM性能指标？请举例说明工具链
在容器化环境中监控JVM性能的核心工具链可概括为：Prometheus+JMX Exporter负责指标（<堆内存使用情况(如Eden、Survivor、Old区占比)、GC频率与耗时(Young GC/Full GC)、线程状态及CPU使用率等关键性能数据 >）采集，Grafana实现可视化看板，配合JDK内置的jstat/jstack进行实时诊断，以及Arthas提供在线调试能力。在Kubernetes环境中可补充SkyWalking或Elastic APM实现全链路监控。这套组合兼顾了指标收集、可视化展示和深度诊断三个维度。
14. 解释你设计的CI/CD流水线中，代码提交到生产部署的完整流程
这套CI/CD流水线从代码提交开始自动触发构建流程，首先进行代码质量检查和安全扫描，通过后进入自动化构建和测试阶段，生成可部署的制品（docker镜像或者jar包）并存入仓库。随后自动部署到测试环境进行综合验证，合格的版本进入生产环境采用渐进式发布策略，配合实时监控和自动回滚机制确保稳定性，最终形成完整的部署审计记录。整个流程实现了从代码到生产的全自动化交付。
15. 如何保证镜像仓库的安全扫描？遇到过哪些安全合规问题？
我们采用三阶段防护体系保障镜像安全：
构建阶段：在CI/CD管道中集成Trivy、Clair等工具进行静态漏洞扫描，检测系统/应用漏洞并与每日更新的漏洞数据库比对
存储阶段：Harbor等私有仓库配置自动扫描，对新镜像执行敏感文件检测和配置验证，仅允许通过检查的镜像被拉取
运行时：对生产环境中的镜像进行动态扫描，持续监控新威胁
整个流程配合镜像签名验证机制，确保完整性和来源可信。
典型问题应对
- 第三方镜像风险：XZ Utils后门事件促使建立更严格的第三方镜像审核流程
- 过期镜像漏洞：通过自动化策略强制定期更新基础镜像
- 信息泄露风险：要求所有Dockerfile经过安全审查，使用distroless等最小化基础镜像
深度考察：
16. 对比Docker与Podman的优缺点，什么场景下会考虑替换？
17. Jenkinsfile中如何实现条件式并行构建？共享库的开发经验
Jenkinsfile中通过parallel指令与when条件判断的组合，可实现根据分支名称、环境变量等参数动态控制并行任务执行（如单元测试与集成测试的并行处理），从而显著提升构建效率。在共享库开发方面，需遵循vars/src/resources的标准目录结构，严格实施版本控制和向后兼容策略，配合完善的文档与单元测试，最终将通用逻辑（如条件式并行构建）封装为可复用的共享库组件，使各项目能灵活配置符合自身需求的构建流程。
18. 容器网络延迟高的根本原因有哪些？你的解决方案
容器网络延迟高主要源于网络架构设计不当（如NAT转换和Overlay封装）、宿主机资源争用（CPU/内存不足）、网络插件性能瓶颈（如iptables规则链过长）以及跨节点通信时的物理限制。解决方案需针对性采用host/macvlan网络模式降低虚拟化开销，通过DPU智能卸载和RDMA协议实现微秒级延迟，优化DNS配置与cgroups资源隔离，并优先选择Cilium等基于eBPF的高性能网络插件，同时调整MTU等网络参数，这些措施需根据具体业务场景组合实施才能有效控制延迟。
19. 如何设计跨主机的容器日志收集方案？EFK栈实践中的坑点
EFK进行搜集日志
但实际部署中需警惕五大核心挑战：Elasticsearch的高资源消耗、Fluentd复杂的日志格式处理、网络波动导致的数据丢失风险、组件版本严格兼容性要求，以及海量日志下的查询性能瓶颈，通常需要通过资源配额控制、日志采样、智能索引管理和完善监控等综合措施来保障系统稳定性。