同样有测试需求的小伙伴可以直接参考这个配置，简单高效，但注意密码的地方
建议要改成自己的哈~ 另外external的那些外部卷提前手工建好，保留你自己的数据，防止以后重建导致数据丢失~）
% cat docker-compose.yml |
name: oracle-apex-dev |
services: |
# --- 数据库服务 --- |
oracle26ai: |
container_name: oracle26ai-free |
image: container-registry.oracle.com/database/free:23.26.1.0-arm64 |
restart: always |
hostname: database # 方便 ORDS 通过名字访问 |
ports: |
- "1521:1521" |
- "5500:5500" |
networks: |
mynet: |
ipv4_address: 192.168.26.26 |
volumes: |
- oradata:/opt/oracle/oradata |
- orafra:/opt/oracle/fast_recovery_area |
- /Users/alfredzhao/media:/u01/media |
environment: |
- TZ=Asia/Shanghai |
- ORACLE_PWD="Cs4321tFrGnY8cKudQbq" |
- ENABLE_ARCHIVELOG=true |
- ENABLE_FORCE_LOGGING=true |
- ORACLE_CHARACTERSET=AL32UTF8 |
- INIT_SGA_SIZE=2048 |
- INIT_PGA_SIZE=1024 |
healthcheck: |
test: ["CMD-SHELL", "lsnrctl status | grep -q 'READY' || exit 1"] |
interval: 20s |
timeout: 10s |
retries: 30 |
# --- ORDS 服务 --- |
ords: |
container_name: ords |
image: container-registry.oracle.com/database/ords:25.4.0 |
restart: on-failure |
ports: |
- "8080:8080" |
networks: |
mynet: |
ipv4_address: 192.168.26.80 |
environment: |
- DBHOST=database |
- DBPORT=1521 |
- DBSERVICENAME=FREEPDB1 |
- ORACLE_PWD="Cs4321tFrGnY8cKudQbq" |
- JDK_JAVA_OPTIONS=-Xms512M -Xmx1024M |
volumes: |
- ords_config:/etc/ords/config |
# 指向你解压后的真实 apex 目录（包含 images 的那一层） |
- /Users/alfredzhao/media/apex-latest/apex:/opt/oracle/apex |
depends_on: |
oracle26ai: |
condition: service_healthy |
# --- 网络定义 --- |
networks: |
mynet: |
external: true |
# --- 数据卷定义 --- |
volumes: |
oradata: |
external: true |
orafra: |
external: true |
ords_config: |
# ORDS 的配置建议持久化，防止重新 Up 后需要再次初始化 |
name: ords_config |
可以看到这个配置中，已经充分考虑到了数据持久化的设计，在数据卷的配置使用中，除了定义的之外，还额外用到一个本地的目录做绑定挂载，方便做一些双向操作。
02 | 快速恢复全套docker环境
有这样的环境，不但方便，还不怕损坏，因为坏了受影响的只是自己。
另外，即便极限测试给搞坏了也可以快速恢复。
比如，上面提到的那个本地的目录做绑定挂载，也就是/Users/alfredzhao/media这个目录。
之前初始化环境时顺手放到Download中，但笔者的笔记本空间实在有限，经常需要清理Download文件夹，为了防止误操作，笔者就把这些需要长久用到的目录做了迁移，迁移完之后笔者就直接修改更新了这个路径在yml配置文件中。
但是，在调用笔者之前写好的重启命令时，发现APEX对图片资源访问不到。
进一步排查发现是容器内的配置并没有更新，发现重启docker并未自动重建容器，从docker ps输出的 CREATED 和 STATUS可以印证这一点，创建时间还是在2个月前：
% docker ps |
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
d4ff05642719 container-registry.oracle.com/database/ords:25.4.0 "docker-entrypoint.sh" 2 months ago Up 2 minutes 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp ords |
cb92789566da container-registry.oracle.com/database/free:23.26.1.0-arm64 "/bin/bash -c $ORACL…" 2 months ago Up 2 minutes (healthy) 0.0.0.0:1521->1521/tcp, [::]:1521->1521/tcp, 0.0.0.0:5500->5500/tcp, [::]:5500->5500/tcp oracle26ai-free |
另外因为笔者这里docker原生环境受限，借用了colima环境，colima启动会自动拉起docker，但前面已经发现自动拉起的docker并没有正确读取到更新的yml文件。
所以处理思路只能是在启动colima环境之后，再手工执行下重建。
检查语法并预览最终配置（这里确认笔者之前改的路径在这里已经变了没有问题）
docker-compose config |
应用并重建（这条命令会重建应用，放心，因为笔者这里已经将所有需要持久化保存的内容都存储在外部卷或外部目录中，重建不会丢失任何历史数据）
docker-compose up -d |
再次检查，发现CREATED字段的时间已更新，是刚刚创建好的：
% docker ps |
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
af956b9d5694 container-registry.oracle.com/database/ords:25.4.0 "docker-entrypoint.sh" 25 seconds ago Up 9 seconds 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp ords |
9dc0e57ceda6 container-registry.oracle.com/database/free:23.26.1.0-arm64 "/bin/bash -c $ORACL…" 27 seconds ago Up 14 seconds (healthy) 0.0.0.0:1521->1521/tcp, [::]:1521->1521/tcp, 0.0.0.0:5500->5500/tcp, [::]:5500->5500/tcp oracle26ai-free |
再次登录本机的测试环境，一切恢复正常：