首页 > 其他分享 >使用 CNN 检测一个人是否戴了口罩

使用 CNN 检测一个人是否戴了口罩

时间:2022-12-20 09:46:25浏览次数:68  
标签:口罩 container runner 检测 image access entrypoint CNN Docker

Override the entrypoint of an image

Introduced in GitLab and GitLab Runner 9.4. Read more about the extended configuration options.

Before explaining the available entrypoint override methods, let’s describe how the runner starts. It uses a Docker image for the containers used in the CI/CD jobs:

  1. The runner starts a Docker container using the defined entrypoint. The default from Dockerfile that may be overridden in the .gitlab-ci.yml file.
  2. The runner attaches itself to a running container.
  3. The runner prepares a script (the combination of before_scriptscript, and after_script).
  4. The runner sends the script to the container’s shell stdin and receives the output.

To override the entrypoint of a Docker image, define an empty entrypoint in the .gitlab-ci.yml file, so the runner does not start a useless shell layer. However, that does not work for all Docker versions.

  • For Docker 17.06 and later, the entrypoint can be set to an empty value.
  • For Docker 17.03 and earlier, the entrypoint can be set to /bin/sh -c/bin/bash -c, or an equivalent shell available in the image.

The syntax of image:entrypoint is similar to Dockerfile’s ENTRYPOINT.

Let’s assume you have a super/sql:experimental image with a SQL database in it. You want to use it as a base image for your job because you want to execute some tests with this database binary. Let’s also assume that this image is configured with /usr/bin/super-sql run as an entrypoint. When the container starts without additional options, it runs the database’s process. The runner expects that the image has no entrypoint or that the entrypoint is prepared to start a shell command.

With the extended Docker configuration options, instead of:

  • Creating your own image based on super/sql:experimental.
  • Setting the ENTRYPOINT to a shell.
  • Using the new image in your CI job.

You can now define an entrypoint in the .gitlab-ci.yml file.

For Docker 17.06 and later:

image:
  name: super/sql:experimental
  entrypoint: [""]

For Docker 17.03 and earlier:

image:
  name: super/sql:experimental
  entrypoint: ["/bin/sh", "-c"]

Define image and services in config.toml

Look for the [runners.docker] section:

[runners.docker]
  image = "ruby:latest"
  services = ["mysql:latest", "postgres:latest"]

The image and services defined this way are added to all jobs run by that runner.

Access an image from a private Container Registry

To access private container registries, the GitLab Runner process can use:

To define which option should be used, the runner process reads the configuration in this order:

  • DOCKER_AUTH_CONFIG CI/CD variable.
  • DOCKER_AUTH_CONFIG environment variable set in the runner’s config.toml file.
  • config.json file in $HOME/.docker directory of the user running the process. If the --user flag is provided to run the child processes as unprivileged user, the home directory of the main runner process user is used.

Requirements and limitations

  • Available for Kubernetes executor in GitLab Runner 13.1 and later.
  • Credentials Store and Credential Helpers require binaries to be added to the GitLab Runner $PATH, and require access to do so. Therefore, these features are not available on shared runners, or any other runner where the user does not have access to the environment where the runner is installed.

Use statically-defined credentials

There are two approaches that you can take to access a private registry. Both require setting the CI/CD variable DOCKER_AUTH_CONFIG with appropriate authentication information.

  1. Per-job: To configure one job to access a private registry, add DOCKER_AUTH_CONFIG as a CI/CD variable.
  2. Per-runner: To configure a runner so all its jobs can access a private registry, add DOCKER_AUTH_CONFIG as an environment variable in the runner’s configuration.

标签:口罩,container,runner,检测,image,access,entrypoint,CNN,Docker
From: https://www.cnblogs.com/sdfasdf/p/16993561.html

相关文章

  • 检测隐藏的系统线程
    隐藏系统线程线程内核对象KTHREAD的ThreadListEntry链接了属于同一个进程的所有线程内核对象。应用层通过ZwQueryInformationThread和进程快照枚举线程就是枚举的这个链表......
  • 毕设系列-检测专题-基于YOLOV5的手势识别系统
    毕设系列-基于YOLOV5的手势识别系统我们之前做过一期基于Yolov5的口罩检测系统(​​手把手教你使用YOLOV5训练自己的目标检测模型-口罩,里面的代码是基于YOLOV56.0开发的,并且......
  • 二阶段目标检测网络-Mask RCNN 详解
    ROIPooling和ROIAlign的区别MaskR-CNN网络结构骨干网络FPNanchor锚框生成规则实验参考资料MaskRCNN是作者KaimingHe于2018年发表的论文ROIPoo......
  • 洒水车水箱液位检测功能如何实现?
    现在的洒水车水箱大部分都没有液位检测功能,只能靠人工查看,而且这种水箱是非透明的,不能直接看到里面液体的状态,容易出现水箱没水设备还在工作,导致设备损坏。而在水箱上安装液......
  • pycaret学习之异常检测
    异常检测是识别与大多数数据明显不同的稀有物品、事件或观察结果的任务。通常,异常项目会转化为某种问题,例如银行欺诈、结构缺陷、医疗问题或文本中的错误。存在三大类异常......
  • Ubuntu 22.04 显示检测到窗口系统采用wayland协议
    解决方法sudovim/etc/gdm3/custom.conf#WaylandEnable=false的注释井号去掉sudoservicegdm3restart参考资料https://zhuanlan.zhihu.com/p/546516064......
  • 基于虚拟数据的行人检测研究(Expecting the Unexpected: Training
    PaperLink:https://arxiv.org/pdf/1703.06283Github: https://github.com/huangshiyu13/RPNplus 摘要:这篇paper探索了如何用虚拟数据或者叫做人工生成的数据对行人检测......
  • msprofiler 性能调优命令行实战(口罩识别推理)
    案例介绍本案例使用口罩识别推理程序作为例子进行演示,硬件平台是华为昇腾310设备(Ascend310),该口罩识别使用目标检测中SSD模型,检测的结果有两个类别:戴口罩的脸、没带口罩的......
  • 核酸检测系统数据库设计
    表设计受检人员表CREATETABLECheckedUser(ch_idvarchar(20),ch_accountvarchar(20),ch_passwordvarchar(20),ch_check_statusinteger,ch_health_......
  • 源码解读之TypeScript类型覆盖检测工具type-coverage
    因为团队内部开启了一个持续的前端代码质量改进计划,其中一个专项就是TS类型覆盖率,期间用到了type-coverage这个仓库,所以借这篇文章分享一下这个工具,并顺便从源码阅读的角......