这段时间忙着弄学校的靶场，都没时间写博客，那就简单地总结一下靶场搭建时候遇到的几个大坑
绝对不是为了水文章
动态题目容器部署
动态flag
动态题目部署最常遇到的问题，就是flag没法挂载
原理是什么呢？
靶场使用的框架是CTFd V2.1.5，适配的动态部署插件是ctfd-owl
一开始我以为owl插件和赵师傅的ctfd-whale插件实现原理是一样的，就依葫画瓢地去clone了CTFTraining，结果发现部署是能部署了，却怎么也调不到想要的动态flag
随便打开一道题的docker-compose.yml，发现预留了一个environment属性，用来修改FLAG环境变量的值
由于前面部署发现flag并没有随不同容器而改变，因此可以推测出owl和whale插件不一样的地方就在动态flag的修改方式不同
因为owl自带了一道题目作为test，并且是一道file upload
对照后发现了一个flag的文件映射，再根据进入容器查看后发现，确实在容器根目录下成功写入了动态flag
因此再次推断，flag就是通过外部flag文件被写入后再映射进去的
但还有一个问题是，如果题目是一些类似sql注入这样的题目，答题者无法直接读取flag文件的，要怎么办呢？
不慌，回到刚刚说到的environment属性
在一道sql注入题的Dockerfile中发现CMD命令会执行一个叫flag.sh的shell文件，文件内容如图
上图的FLAG是我自己添加进去的，在原版CTFTraining中是没有’cat /flag‘这句代码的。这里经过查阅，发现export为设置环境变量，所以如果想让flag写入到数据库中，就可以通过这样的形式写入进去
环境变量配置
正如上面所说，想要给一些无法直接接触到flag文件的题目配置动态flag，就需要使用环境变量赋值。可是，当我再一次进行尝试时，发现还是部署不上去，导致在这个地方卡了整整两天
直到某天在群上，我被罗少的一句话点醒
“用./形式运行的子shell是无法修改父shell环境变量的，但用source运行的话就不是子shell运行，而是直接被系统shell运行”
打开Dockerfile后发现，CMD命令的确使用的是./运行方法，修改后如下
就成功解决问题啦~
（还是要感谢罗少的提示）
无法修改的容器
当我修改完我的docker配置文件后，正当一切准备就绪，激动地按下docker-compose up -d后，发现容器非但没给我部署上正确flag，甚至连原本自带的flag都没了，在这个地方又卡了整整一天
正当我百思不得其解的时候，胡乱翻看网上博客，才想起来在docker-compose中还带有image这个属性，经过翻看文档后才得知，docker compose在部署容器集群时，会优先根据image属性读取镜像库中的镜像，而不是利用Dockerfile的配置自己制作容器。
就这样，删掉image属性和本地悬挂镜像后，一切便大功告成
（果然还是得听罗少的话，用什么之前都得好好看文档）
就先写到这儿了，要是碰到什么问题再补充叭