Разное

При работе в finereader с документами имеющими одинаковое расположение: ABBYY FineReader Server против хаоса. Как наше решение удаляет дубликаты и наводит порядок в бизнес-документах?

Содержание

ABBYY FineReader Server против хаоса. Как наше решение удаляет дубликаты и наводит порядок в бизнес-документах?

Привет, Хабр! Наверняка вы помните посты о том, как наш ABBYY Recognition Server помогал в оцифровке материалов и каталогов библиотек на Сахалине, в Латвии, Великобритании и в других странах. Мы давно не рассказывали об этом продукте, а ведь все это время он развивался. Мы обучили его новым способностям, прокачали его навыки с помощью интеллектуальных OCR-технологий последнего поколения и даже дали новое имя – ABBYY FineReader Server. Объясняем: под общим брендом FineReader мы объединили все продукты для распознавания, конвертации и редактирования документов.

Сегодня ABBYY FineReader Server помогает не только оцифровывать материалы из библиотек и архивов, но и упорядочивать хранение информации в крупных компаниях. Например, группа FESCO оцифровывает бухгалтерские счета и транспортные накладные и отправляет их в единый электронный архив, чтобы быстрее проводить транзакции, а сотрудники PwC прямо с мобильного телефона конвертируют фотографии счетов, договоров и других документов в PDF с возможностью полнотекстового поиска и отправляют их в корпоративные системы.

В США юридическая фирма Kantor & Kantor использует это решение, чтобы быстрее находить значимую информацию в тысячах страниц судебных дел.

В этом посте мы расскажем о нескольких новых возможностях ABBYY FineReader Server: как они технически реализованы и для чего крупные компании пользуются ими.

По данным исследования O’Reilly «Состояние качества данных в 2020 году», большинство крупных компаний испытывают трудности при работе с корпоративной информацией. Например, 60% опрошенных отметили большое число корпоративных источников и дублирование информации в них, а 49% – отсутствие контроля над качеством входящих данных. Дубликаты – не единственная проблема. Информация устаревает, а объемные и уже не актуальные файлы замедляют поиск информации, затрудняют работу корпоративных систем, да и занимают место, что напрямую влияет на стоимость хранения данных. Это не тот балласт, который стоит переносить в новенькие DMS или ECM-системы.

На самом деле такие проблемы знакомы и каждому пользователю.

Достаточно иногда взглянуть на свой рабочий стол, чтобы понять: пора навести порядок в этом зоопарке. Что уж говорить о корпоративном хранилище большой компании, где сотрудников тысячи, а документов — миллионы.

Справиться с этими проблемами – управлять потоками документов, хранить только нужные данные и в необходимом вам формате – помогают технологии интеллектуальной обработки информации. Ниже мы расскажем о нескольких возможностях, которые появились в ABBYY FineReader Server и помогут избавиться от хаоса:


  • Автоматическое удаление полных дубликатов;
  • Предварительная обработка документов;
  • Улучшенное распознавание большинства популярных штрих-кодов, включая ISBN, PDF417, Aztec и QR;
  • Единый веб-интерфейс для распознавания и конвертации файлов;
  • Улучшенное сжатие цветных изображений.

Полные дубликаты: найти и остановить

В компаниях любого размера, как правило, есть электронные архивы, которые наполнялись в течение многих лет. Допустим, в вашем SharePoint’е исторически накопилось много файлов. Что там хранится и как можно быстро найти нужный документ – иногда большая тайна даже для его создателей. Но не для ABBYY FineReader Server. В нем есть режим работы

Аудит, который позволяет посмотреть, какие документы размещены в хранилище и сколько их.

Сначала вы получите общую статистику по файлам: сколько изображений в графическом формате, скан-копий документов, PDF с текстовым слоем, документов MS Word. Кроме того, вы увидите и общее количество файлов в других, не текстовых форматах: видео, аудио, исполняемые файлы, системные файлы приложений и т.д. Их ABBYY FineReader Server не обрабатывает, но они существуют в архиве и это стоит учитывать. Аудит также определит, сколько всего документов стоит конвертировать, какие в хранилище есть группы дубликатов и где они лежат. Расскажем о них подробнее.


Хэш-сумма – это уникальный идентификатор файла. Он высчитывается компьютером путем математических преобразований информации, содержащейся в нем. Если файлы являются дубликатами, то хэши у них будут совпадать, даже если у файлов разные имена и расширения.

При аудите FRS считает хэш-сумму каждого файла, а затем сравнивает их между собой. Если они совпадают, значит, файлы, скорее всего, являются полными дубликатами и попадут в отчет:

На скриншоте видна статистика: сколько картинок и сканов нужно распознать перед конвертацией, сколько текстовых документов можно перевести в PDF и сколько в хранилище файлов, которые невозможно обработать с помощью FRS. Под табличкой есть отчет по дубликатам и по файлам, чей размер больше 20 МB.

Допустим, компания решила организовать централизованный электронный архив на базе SharePoint вместо десятка разрозненных хранилищ. Для этого сначала необходимо проанализировать, какие файлы годами копились и сейчас содержатся в архивах. Вдруг там полно дубликатов и устаревших документов? А компании как раз не нужны такие копии, потому что хочется хранить меньше документов и легче искать в них нужную информацию. Проведя аудит, можно аккуратно заглянуть в черную дыру электронное хранилище и посмотреть, есть ли там дубликаты и если да, то о каких документах речь. Аудит удобно запускать как первый шаг, если у компании большое хранилище и, например, необходимо посчитать, на сколько страниц вам понадобится лицензия FRS, чтобы обработать файлы.

Второй режим работы FRS – Обработка. Если компания не хочет отправлять в новое хранилище дубликаты документов, то в программе можно поставить галочку Исключить файлы-дубликаты.

В этом случае FRS обрабатывает файлы, конвертирует, в этот же момент считает хэш-сумму каждого из них и сравнивает ее с хэшем каждого уже найденного в хранилище файла. Решение обрабатывает один файл из группы дубликатов, а остальные – пропускает. Если содержимое двух файлов полностью одинаковое, а название файлов – разное, то такие файлы тоже считаются дубликатами.

Когда обработка завершена, FRS снова выведет отчет по дубликатам. Это сделано для тех пользователей, которые не знают про аудит, не хотят его запускать или случайно пропускают этот этап. У них может появиться вопрос: «А были ли вообще в хранилище дубликаты? А какие это файлы? Много ли их?». В отчете будет показана группа дубликатов.


Как повысить качество изображения

При обработке в FRS файлы проходят несколько стадий. Например, изображения, которые нужно распознать, сначала отправляются на так называемую предобработку. На этом этапе происходит применение различных фильтров к документу, чтобы улучшить качество его распознавания. Например, если у пользователя сканы низкого качества, он может попробовать поменять набор настроек, чтобы повысить качество изображения: допустим, настроить яркость, контрастность, уровень интенсивности света и тени, повернуть, обрезать лишние границы, осветлить фон и др.

В большинстве случаев хватает профиля предобработки, который настроен в FRS по умолчанию. Это оптимальный набор фильтров, который повышает качество большого количества документов. Решение автоматически выставляет разрешение, подходящее для распознавания текста, определяет, не повернуто ли изображение, исправляет перекосы.


Пользователь может и сам подобрать оптимальный состав фильтров для своих документов и объединить свои группы настроек в профиль. Это удобно, чтобы каждый раз не выставлять 100500 галок. Профилей может быть сколько угодно – для обработки фото, для сканов и т.д.

Свои профили предобработки изображений настраивают пользователи и компании, у которых:

• Очень специфичные документы, например, какие-то фотографии, сделанные в темном помещении.
• Документы, на основе которых будут приниматься критически важные решения, и тут важно бороться за каждый процент качества распознавания, который можно повысить.
• Задача – распознать и конвертировать файлы для дальнейшей отправки документов в интеллектуальные системы для анализа и извлечения текстовой информации с помощью NLP-технологий – например, на платформах eDiscovery. Для них качество текста очень важно, и малейшая опечатка в слове может привести к неправильным результатам. Например, на каком-то слове не выделится сущность.


Поколдовали со штрихкодами

По сравнению с предыдущей версией решения наши разработчики значительно улучшили распознавание ISBN, PDF-417, Aztec и QR-кодов. В некоторых категориях качество повысилось на 15%. При этом скорость обработки увеличилась на 20%.

Расскажем, в каких случаях компании используют такие штрихкоды и для чего их необходимо распознавать.

Первый. В логистические, транспортные и другие компании часто поступают большие файлы, в которых содержатся сразу много сканов разных документов – например, товарных накладных. И чтобы поделить этот файл на самостоятельные документы, на первой странице каждой новой накладной помещают штрихкод. В FRS есть функция разделения документов по штрихкоду. В результате на экспорте вместо одного большого комбинированного документа получается несколько аккуратно поделенных файлов.

Второй. В банках, розничных магазинах и других компаниях иногда само значение штрихкода может быть как-то использовано, допустим, в нем может быть зашифровано название файла. Например, у большой торговой сети может быть поток документов от разных поставщиков. Они используют разные штрихкоды. FRS поможет обрабатывать весь массив документов и сразу разложить счета от каждого поставщика в отдельные папки.

Кстати, в одном из европейских банков у нас был любопытный кейс. В компанию поступали бумажные письма со штрихкодами, в них были закодированы имена адресатов. Клиент хотел оцифровывать такие штрихкоды, чтобы уже по электронной почте отправлять оцифрованный документ тому адресату, которому пришло бумажное письмо.


Распознавание и конвертирование прямо в вебе

Сотрудникам крупных компаний по работе часто нужно быстро распознавать и конвертировать файлы в нужные им форматы. Например, бухгалтерия получает от контрагентов сканы товарных накладных или счета в разных графических форматах: JPEG, TIFF, PDF. Специалистам нужно конвертировать все документы в единый формат, допустим, в PDF с текстовым слоем, а затем пересылать дальше, положить в хранилище и т.д.

Раньше в FRS было две возможности для такой конвертации.

Первая: сисадмины настраивали две расшаренные папки. В одну из них конечный пользователь помещал свой документ, а через некоторое время в выходной папке появлялся документ, уже сконвертированный в нужный формат.

Вторая. Пользователь отправлял на определенный адрес письмо с вложенным документом, который нужно сконвертировать или распознать. В ответ ему в почту приходил email с результатом распознавания.

Оба этих способа существуют и сейчас. Но поскольку все движется в сторону веба, то в FRS появилась и третья возможность – конвертация и распознавание документов через веб-интерфейс. Мы постарались сделать его максимально простым и понятным.

Загружаешь файл, выбираешь один или несколько форматов, в которые нужно конвертировать документ, а также выбираешь языки, которые используются в документе. Получаешь результат.

Такой сервис может пригодится в любой компании, где людям нужно массово конвертировать файлы. Причем конечным пользователям не придется тратить время на настройки. Все уже готово к работе, достаточно закинуть файл и получить результат.


Качество изображения лучше, а вес — меньше

В FRS мы усовершенствовали алгоритмы сжатия MRC, чтобы обеспечить высокое качество цветных изображений при сжатии тяжелых файлов. Во-первых, подобрали более оптимальные параметры сжатия MRC для режимов минимального размера и сбалансированного. Во-вторых, использовали нестрогий детектор определения цветности: это значит, что «почти черно-белые» изображения обрабатываются как черно-белые. Это позволяет заметно уменьшать их размер. Тестирование фичи на образцах из базы изображений ABBYY показало, что уровень сжатия файлов с цветными картинками стал лучше на 10-30%.

Подобное сжатие необходимо для конвертирования файлов в формат PDF. Чем меньше размер документа с изображением, тем быстрее он открывается на мобильном устройстве, загружается с сайта или отправляется по почте.


В качестве заключения

Эта статья рассказывает о самых интересных и необходимых на наш взгляд новых фичах ABBYY FineReader Server. Попробовать их можно уже сейчас – скачайте триал-версию продукта бесплатно. Если вам интересно узнать больше подробностей о FRS, то пишите в комментариях свои вопросы!

ABBYY FineReader делит страницу пополам

Программное обеспечение
  • Recluse
  • 17.10.2020
  • 1 088
  • 0
  • 6
  • 6
  • 0
  • Содержание статьи

Отключение деления страницы

При сканировании листов программой ABBYY FineReader, можно столкнуться с тем, что альбомные листы программа делит пополам - будто бы были отсканированы два листа, а не один. Те, кому такие "навороты" программы не нужны, могут легко отключить деление страниц в настройках программы. Сделать это можно в двух местах:

В настройках программы

  1. Для отключения разбивки страницы на две части, необходимо открыть настройки, нажав в главном верхнем меню кнопку "Инструменты", и выбрав пункт раскрывшегося меню "Настройки".
  2. В открывшемся окне настроек, нужно перейти на вкладку "Обработка изображений".
  3. На данной вкладке нужно найти раздел "Настройки предобработки изображений", который находится в самом низу. Там будет пункт "Делить разворот книги", с которого нужно снять галочку.
  4. Для применения настроек нужно закрыть окно нажатием кнопок "ОК".

В настройках сканирования

  1. Можно отключить деление страницы и непосредственно в интерфейсе сканирования. Для этого, нужно в окне сканирования нажать на расположенную внизу левой части окна надпись "Настройки предобработки изображений".
  2. Откроется небольшое окно, где нужно снять галочку с пункта "Делить разворот книги".
  3. Для сохранения и применения настроек нужно нажать на кнопку "Сохранить".

Работа с документом ABBYY FineReader

Работа с документом FineReader

При работе с документом ABBYY FineReader доступны следующие операции:

  • Создать документ

    • В меню Файл выберите пункт Новый документ FineReader, или
    • На главной панели инструментов нажмите кнопку .
  • Удалить страницу из документа

    • В меню Страница выберите пункт Удалить страницу из документа, или
    • В контекстном меню выделенной страницы в окне Страницы выберите Удалить страницу из документа.

    Чтобы удалить несколько страниц, выделите несколько страниц в окне Страницы.

  • Открыть документ

    При запуске ABBYY FineReader по умолчанию открывает новый документ FineReader.

    Замечание. Если вы хотите, чтобы при запуске программа открывала последний документ, с которым вы работали, отметьте опцию Открывать последний документ при запуске ABBYY FineReader на закладке Дополнительные диалога Опции (меню Сервис>Опции…).

    Как открыть документ:

    1. В меню Файл выберите пункт Открыть документ FineReader…
    2. В открывшемся диалоге Открыть документ FineReader выберите нужный документ.

    Замечание. Документ ABBYY FineReader также можно открыть непосредственно из Проводника Windows (такие документы обозначаются значком ), выбрав в контекстном меню документа пункт Открыть в ABBYY FineReader.

  • Добавить изображение в документ

    • В меню Файл выберите пункт Открыть PDF/изображение…
    • В диалоге Открыть изображение выберите одно или несколько изображений и нажмите кнопку Открыть. Изображение будет добавлено в открытый документ, и его копия будет сохранена в папке документа.

    Замечание. Вы можете добавить изображение из Проводника Windows:

    • Выделите в Проводнике Windows один или несколько файлов с изображениями, затем в контекстном меню выберите пункт Открыть в ABBYY FineReader.

      Если на вашем компьютере уже открыт ABBYY FineReader, выделенные файлы будут добавлены в текущий документ, в противном случае ABBYY FineReader запустится автоматически, и файлы будут добавлены в новый документ.

  • Сохранить документ

    1. В меню Файл выберите пункт Сохранить документ FineReader…
    2. В открывшемся диалоге Сохранить документ FineReader укажите название документа и папку, где будет храниться данный документ.

    Внимание! При сохранении документа ABBYY FineReader сохраняются не только все его страницы (изображения и текст), но и дополнительные файлы, созданные в процессе работы с этим документом: эталон, пользовательские языки.

  • Закрыть документ

    • Чтобы закрыть выбранную страницу документа, в меню Документ выберите пункт Закрыть текущую страницу.
    • Чтобы закрыть весь документ, в меню Файл выберите пункт Закрыть документ FineReader.
  • Сохранить настройки документа

    Как сохранить настройки документа в отдельный файл:

    1. Откройте диалог Опции (меню Сервис>Опции…) на закладке Дополнительные.
    2. Нажмите кнопку Сохранить опции…

      Замечание. Чтобы вернуться к опциям, устанавливаемым системой по умолчанию, нажмите кнопку Настройки по умолчанию.

    3. В открывшемся диалоге Сохранить опции укажите имя файла.

    В этот файл будут сохранены:

    • Все настройки с закладок Документ, Сканировать/Открыть, Распознать, Сохранить, Вид и Дополнительные диалога Опции (меню Сервис>Опции…)
    • Путь к папке, в которой хранятся пользовательские языки и их словари; а также группы языков, пользовательские с

      Работа с документом ABBYY FineReader

Ссылка на файл Dockerfile

| Документация Docker

Расчетное время чтения: 81 минута

Docker может автоматически создавать образы, читая инструкции из Dockerfile . Dockerfile - это текстовый документ, содержащий все команды пользователь может вызвать командную строку для сборки изображения. Использование docker build пользователи могут создать автоматизированную сборку, которая выполняет несколько командных строк инструкции по порядку.

На этой странице описаны команды, которые можно использовать в файле Dockerfile .Когда вы Прочитав эту страницу, обратитесь к Dockerfile Best Практики для ориентированного на чаевые гида.

Использование

Команда docker build создает образ из файл Dockerfile и контекст . Контекст сборки - это набор файлов в указанное местоположение PATH или URL . PATH - это каталог на вашем локальном файловая система. URL-адрес - это расположение репозитория Git.

Контекст обрабатывается рекурсивно.Итак, PATH включает все подкаталоги и URL-адрес включает репозиторий и его подмодули. Этот пример показывает команда сборки, которая использует текущий каталог в качестве контекста:

  $ сборка докеров.

Отправка контекста сборки демону Docker 6.51 МБ
...
  

Сборка выполняется демоном Docker, а не интерфейсом командной строки. Первым делом сборка процесс отправляет весь контекст (рекурсивно) демону. В большинстве случаев лучше всего начать с пустого каталога в качестве контекста и сохранить Dockerfile в этом каталоге.Добавьте только файлы, необходимые для создания Dockerfile.

Предупреждение

Не используйте корневой каталог / в качестве ПУТЬ , так как это вызывает сборку передать все содержимое вашего жесткого диска демону Docker.

Чтобы использовать файл в контексте сборки, Dockerfile ссылается на указанный файл в инструкции, например, COPY . Для увеличения сборки производительности, исключите файлы и каталоги, добавив . dockerignore в каталог контекста. Для получения информации о том, как создать .dockerignore файл см. документацию на этой странице.

Традиционно Dockerfile называется Dockerfile и находится в корне контекста. Вы используете флаг -f с docker build , чтобы указать на Dockerfile в любом месте вашей файловой системы.

  $ docker build -f / путь / к / a / Dockerfile.
  

Вы можете указать репозиторий и тег для сохранения нового изображения, если сборка выполнена успешно:

  $ docker build -t shykes / myapp. 

Чтобы пометить изображение в нескольких репозиториях после сборки, добавить несколько параметров -t при запуске команды build :

  $ docker build -t shykes / myapp: 1.0.2 -t shykes / myapp: latest.
  

Перед тем, как демон Docker выполнит инструкции из файла Dockerfile , он выполняет предварительная проверка Dockerfile и возвращает ошибку, если синтаксис неверен:

  $ docker build -t test / myapp. Отправка контекста сборки демону Docker 2.048 kB
Ответ демона об ошибке: Неизвестная инструкция: RUNCMD
  

Демон Docker последовательно запускает инструкции из файла Dockerfile , фиксация результата каждой инструкции к новому изображению, если необходимо, прежде чем, наконец, вывести идентификатор вашего новое изображение. Демон Docker автоматически очистит контекст, который вы послал.

Обратите внимание, что каждая инструкция выполняется независимо и вызывает новый образ. будет создан - поэтому RUN cd / tmp не повлияет на следующий инструкции.

Когда это возможно, Docker будет повторно использовать промежуточные образы (кеш), для значительного ускорения процесса сборки докеров . На это указывает сообщение Using cache в выводе консоли. (Дополнительные сведения см. В руководстве по передовым методам Dockerfile :

  $ docker build -t svendowideit / ambassador.

Отправка контекста сборки демону Docker 15,36 КБ
Шаг 1/4: ИЗ альпийского: 3. 2
 ---> 31f630c65071
Шаг 2/4: ОБСЛУЖИВАНИЕ SvenDowideit @ home.org.au
 ---> Использование кеша
 ---> 2a1c

f5f Шаг 3/4: ЗАПУСТИТЕ apk update && apk add socat && rm -r / var / cache / ---> Использование кеша ---> 21ed6e7fbb73 Шаг 4/4: CMD env | grep _TCP = | (sed 's /.*_ ПОРТ _ \ ([0-9] * \) _ TCP = tcp: \ / \ / \ (. * \): \ (. * \) / socat -t 100000000 TCP4-LISTEN: \ 1 , fork, reuseaddr TCP4: \ 2: \ 3 \ & / '&& echo wait) | ш ---> Использование кеша ---> 7ea8aef582cc Успешно построенный 7ea8aef582cc

Кэш сборки используется только для образов, имеющих локальную родительскую цепочку.Это означает что эти образы были созданы предыдущими сборками или всей цепочкой образов был загружен docker load . Если вы хотите использовать кеш сборки определенного image вы можете указать его с помощью опции --cache-from . Изображения, указанные с --cache-from не обязательно иметь родительскую цепочку и может быть извлечен из другой реестры.

Когда вы закончите сборку, вы готовы изучить Pushing a репозиторий в свой реестр .

BuildKit

Начиная с версии 18.09, Docker поддерживает новый бэкэнд для выполнения ваших сборки, предоставляемые moby / buildkit проект. Бэкэнд BuildKit предоставляет множество преимуществ по сравнению со старым реализация. Например, BuildKit может:

  • Обнаружение и пропуск неиспользуемых этапов сборки
  • Распараллелить независимые этапы сборки
  • Постепенно переносите только измененные файлы в контексте сборки между сборками
  • Обнаружение и пропуск передачи неиспользуемых файлов в контексте сборки
  • Используйте внешние реализации Dockerfile со многими новыми функциями
  • Избегайте побочных эффектов с остальной частью API (промежуточные изображения и контейнеры)
  • Установите приоритет кэша сборки для автоматического удаления

Чтобы использовать бэкэнд BuildKit, вам необходимо установить переменную среды DOCKER_BUILDKIT = 1 в интерфейсе командной строки перед вызовом сборки докера .

Чтобы узнать об экспериментальном синтаксисе Dockerfile, доступном для BuildKit-based сборки относятся к документации в репозитории BuildKit.

Формат

Вот формат файла Dockerfile :

  # Комментарий
ИНСТРУКЦИЯ аргументы
  

В инструкции регистр не учитывается. Однако по соглашению они быть ЗАГЛАВНЫМ, чтобы легче отличать их от аргументов.

Docker запускает инструкции в файле Dockerfile по порядку. Dockerfile должен Начните с инструкции ОТ . Это может быть после парсера директивы, комментарии и глобальная область видимости ARG. Инструкция FROM указывает Parent Изображение , с которого вы находитесь здание. ИЗ может предшествовать только одна или несколько инструкций ARG , которые объявить аргументы, которые используются в из строк в файле Dockerfile .

Docker обрабатывает строки, в которых начинаются с с # , как комментарий, если только строка не допустимая директива парсера. Маркер # где угодно else в строке рассматривается как аргумент. Это позволяет использовать такие утверждения, как:

  # Комментарий
RUN echo "мы запускаем несколько интересных вещей"
  

Строки комментариев удаляются перед выполнением инструкций Dockerfile, которые означает, что комментарий в следующем примере не обрабатывается оболочкой выполнение команды echo , и оба приведенных ниже примера эквивалентны:

  RUN echo hello \
# комментарий
Мир
  

Символы продолжения строки в комментариях не поддерживаются.

Примечание о пробеле

Для обратной совместимости начальные пробелы перед комментариями ( # ) и инструкции (такие как RUN ) игнорируются, но не рекомендуется. Ведущие пробелы не сохраняется в этих случаях, поэтому следующие примеры эквивалент:

  # это строка комментария
    RUN echo привет
Беги эхо мир
  
  # это строка комментария
RUN echo привет
Беги эхо мир
  

Обратите внимание, однако, что пробел в команде аргументов , таких как команды следующие RUN , сохраняются, поэтому в следующем примере печатается `hello world` с ведущими пробелами, как указано:

  RUN echo "\
     Здравствуйте\
     Мир"
  

Директивы парсера

Директивы парсера необязательны и влияют на способ, которым последующие строки в файле Dockerfile обрабатываются . Директивы парсера не добавляют слои в сборку, и не будет отображаться как этап сборки. Директивы парсера записываются как специальный тип комментария в виде # директива = значение . Единая директива можно использовать только один раз.

После обработки комментария, пустой строки или инструкции конструктора Docker больше не ищет директивы парсера. Вместо этого он обрабатывает все отформатированное как директива парсера в качестве комментария и не пытается проверить, может ли он быть директивой парсера.Следовательно, все директивы парсера должны быть в самом верхняя часть Dockerfile .

Директивы парсера не чувствительны к регистру. Однако по соглашению они быть строчными. Соглашение также должно включать пустую строку после любого директивы парсера. Символы продолжения строки не поддерживаются парсером директивы.

Из-за этих правил все следующие примеры недействительны:

Недействителен из-за продолжения строки:

Недействителен из-за двукратного появления:

  # директива = значение1
# директива = значение2

ОТ ImageName
  

Считается комментарием из-за появления после инструкции строителя:

  ИЗ ImageName
# директива = значение
  

Считается комментарием из-за появления после комментария, не являющегося синтаксическим анализатором директива:

  # О моем dockerfile
# директива = значение
ОТ ImageName
  

Директива unknown обрабатывается как комментарий, так как не распознается. В кроме того, известная директива обрабатывается как комментарий из-за появления после комментарий, который не является директивой парсера.

  # unknowndirective = значение
# knowndirective = значение
  

В директиве синтаксического анализатора разрешены пробелы, не прерывающие строку. Следовательно следующие строки обрабатываются одинаково:

  # директива = значение
# директива = значение
# директива = значение
# директива = значение
# dIrEcTiVe = значение
  

Поддерживаются следующие директивы парсера:

синтаксис

  # syntax = [ссылка на удаленное изображение]
  

Например:

  # синтаксис = docker / dockerfile
# синтаксис = docker / dockerfile: 1.0
# синтаксис = docker.io / docker / dockerfile: 1
# syntax = docker / dockerfile: 1.0.0-экспериментальный
# синтаксис = example.com / user / repo: tag @ sha256: abcdef ...
  

Эта функция доступна, только если используется серверная часть BuildKit.

Синтаксическая директива определяет расположение построителя Dockerfile, который используется для создание текущего Dockerfile. Бэкэнд BuildKit позволяет легко использовать внешние реализации построителей, которые распространяются как образы Docker и выполнить внутри среды песочницы контейнера.

Реализация Custom Dockerfile позволяет:

  • Автоматически получать исправления без обновления демона
  • Убедитесь, что все пользователи используют одну и ту же реализацию для создания вашего файла Docker.
  • Используйте новейшие функции без обновления демона
  • Попробуйте новые экспериментальные или сторонние функции

Официальные релизы

Docker распространяет официальные версии образов, которые можно использовать для сборки Dockerfiles в репозитории docker / dockerfile в Docker Hub.Есть два каналы, на которых выпускаются новые изображения: стабильные и экспериментальные.

Стабильный канал следует за семантическим управлением версиями. Например:

  • docker / dockerfile: 1.0.0 - разрешить только неизменяемую версию 1.0.0
  • docker / dockerfile: 1.0 - разрешить версии 1.0. *
  • docker / dockerfile: 1 - разрешить версии 1. *. *
  • docker / dockerfile: latest - последний выпуск на стабильном канале

Экспериментальный канал использует инкрементное управление версиями с основным и второстепенным компонент из стабильного канала на момент выпуска.Например:

  • docker / dockerfile: 1.0.1-экспериментальный - разрешить только неизменяемую версию 1.0.1-экспериментальный
  • docker / dockerfile: 1.0-experimental - последние экспериментальные выпуски после 1.0
  • docker / dockerfile: экспериментальный - последний выпуск на экспериментальном канале

Вам следует выбрать канал, который лучше всего соответствует вашим потребностям. Если ты только хочешь исправления ошибок, вы должны использовать docker / dockerfile: 1.0 . Если вы хотите извлечь выгоду из экспериментальные функции, вам следует использовать экспериментальный канал. Если вы используете экспериментальный канал, более новые выпуски могут не иметь обратной совместимости, поэтому рекомендуется использовать неизменяемый вариант полной версии.

Основные сборки и ночные выпуски функций см. В описании в исходный репозиторий.

побег

или

Директива escape устанавливает символ, используемый для escape-символов в Dockerfile .Если не указан, escape-символ по умолчанию - \ .

Управляющий символ используется как для экранирования символов в строке, так и для избежать новой строки. Это позволяет инструкции Dockerfile охватывают несколько строк. Обратите внимание, что независимо от того, экранирует ли парсер директива включена в Dockerfile , экранирование не выполняется в команда RUN , кроме конца строки.

Установка escape-символа на ` особенно полезна на Windows , где \ - разделитель путей к каталогам. ` согласован с Windows PowerShell.

Рассмотрим следующий пример, который неочевидным образом дает сбой на Windows . Второй \ в конце второй строки будет интерпретироваться как escape для новой строки вместо цели escape из первых \ . Точно так же \ в конце третьей строки будет, если предположить, что это действительно обрабатывается как инструкция, потому что она рассматривается как продолжение строки.Результат этого файла докеров заключается в том, что вторая и третья строки считаются одним инструкция:

  С microsoft / nanoserver
КОПИРОВАТЬ testfile.txt c: \\
RUN dir c: \
  

Результатов в:

  PS C: \ John> сборка докеров -t cmd.
Отправка контекста сборки демону Docker 3.072 kB
Шаг 1/2: С microsoft / nanoserver
 ---> 22738ff49c6d
Шаг 2/2: КОПИРОВАТЬ testfile. txt c: \ RUN dir c:
GetFileAttributesEx c: RUN: системе не удается найти указанный файл.
PS C: \ Джон>
  

Одним из решений вышеперечисленного было бы использование / в качестве цели для COPY инструкция и директория .Однако этот синтаксис в лучшем случае сбивает с толку, поскольку это не так. естественно для путей на Windows и в худшем случае подвержен ошибкам, так как не все команды на Windows поддерживает / в качестве разделителя пути.

При добавлении директивы парсера escape следующий Dockerfile преуспеет как ожидается с использованием естественной семантики платформы для путей к файлам в Windows :

  # escape = `

С microsoft / nanoserver
КОПИРОВАТЬ тестовый файл.txt c: \
RUN dir c: \
  

Результатов в:

  PS C: \ John> docker build -t завершается успешно --no-cache = true.
Отправка контекста сборки демону Docker 3. 072 kB
Шаг 1/3: С microsoft / nanoserver
 ---> 22738ff49c6d
Шаг 2/3: КОПИРОВАТЬ testfile.txt c: \
 ---> 96655de338de
Снятие промежуточного контейнера 4db9acbb1682
Шаг 3/3: ЗАПУСК dir c: \
 ---> Запуск в a2c157f842f5
 Том на диске C не имеет метки.
 Серийный номер тома 7E6D-E0F7.

 Каталог c: \

05.10.2016 17:04 1,894 Лицензия.текст
05.10.2016 14:22  Программные файлы
05.10.2016 14:14  Программные файлы (x86)
28.10.2016 11:18 62 testfile.txt
28.10.2016 11:20  Пользователи
28.10.2016 11:20  Windows
           2 Файл (ы) 1,956 байт
           4 Dir (s) 21,259,096,064 байта свободно
 ---> 01c7f3bef04f
Снятие промежуточного контейнера a2c157f842f5
Успешно построен 01c7f3bef04f
PS C: \ Джон>
  

Замена окружающей среды

Переменные среды (объявленные с помощью оператора ENV ) также могут быть используются в определенных инструкциях как переменные, которые интерпретируются Dockerfile .Экраны также обрабатываются для включения синтаксиса, подобного переменному в заявление буквально.

Переменные среды обозначены в Dockerfile либо с $ имя_переменной или $ {имя_переменной} . К ним относятся одинаково, и синтаксис скобок обычно используется для решения проблем с именами переменных без пробел, например $ {foo} _bar .

Синтаксис $ {variable_name} также поддерживает некоторые из стандартных bash модификаторы, указанные ниже:

  • $ {variable: -word} указывает, что если переменная установлена, то результат будет это значение.Если переменная не установлена, результатом будет слово .
  • $ {переменная: + слово} указывает, что если переменная установлена, то слово будет результат, иначе результатом будет пустая строка.

Во всех случаях слово может быть любой строкой, включая дополнительную среду переменные.

Экранирование возможно путем добавления \ перед переменной: \ $ foo или \ $ {foo} , например, будет преобразовано в литералы $ foo и $ {foo} соответственно.

Пример (проанализированное представление отображается после # ):

  ОТ busybox
ENV FOO = / бар
WORKDIR $ {FOO} # WORKDIR / бар
ДОБАВИТЬ . $ FOO # ДОБАВИТЬ. /бар
COPY \ $ FOO / quux # COPY $ FOO / quux
  

Переменные среды поддерживаются следующим списком инструкций в файл Dockerfile :

  • ДОБАВИТЬ
  • КОПИЯ
  • ENV
  • EXPOSE
  • ИЗ
  • ТАБЛИЧКА
  • СИГНАЛ ОСТАНОВА
  • ПОЛЬЗОВАТЕЛЬ
  • ОБЪЕМ
  • WORKDIR
  • ONBUILD (в сочетании с одной из поддерживаемых инструкций выше)

При замене переменной среды будет использоваться одно и то же значение для каждой переменной на протяжении всей инструкции.Другими словами, в этом примере:

  ENV abc = привет
ENV abc = пока def = $ abc
ENV ghi = $ abc
  

приведет к def , имеющему значение hello , а не bye . Тем не мение, ghi будет иметь значение bye , потому что он не является частью той же инструкции которые устанавливают abc на bye .

.dockerignore файл

Прежде чем интерфейс командной строки докера отправит контекст демону докера, он выглядит для файла с именем .dockerignore в корневом каталоге контекста. Если этот файл существует, CLI изменяет контекст, чтобы исключить файлы и каталоги, соответствующие шаблонам в нем. Это помогает избежать без необходимости отправлять большие или конфиденциальные файлы и каталоги на daemon и потенциально добавляя их к изображениям, используя ADD или COPY .

CLI интерпретирует файл .dockerignore как разделенный новой строкой список шаблонов, похожих на файловые глобусы оболочек Unix.Для В целях сопоставления корень контекста считается как рабочий и корневой каталог. Например, выкройки / foo / bar и foo / bar оба исключают файл или каталог с именем bar в подкаталоге foo PATH или в корне git репозиторий URL . Ни то, ни другое не исключает ничего.

Если строка в файле .dockerignore начинается с # в столбце 1, то эта строка рассматривается как комментарий и игнорируется перед интерпретацией CLI.

Вот пример файла .dockerignore :

  # comment
* / темп *
* / * / темп *
темп?
  

Этот файл вызывает следующее поведение сборки:

Правило Поведение
# комментарий Игнорируется.
* / темп * Исключить файлы и каталоги, имена которых начинаются с temp , из любого непосредственного подкаталога корня.Например, простой файл /somedir/ Contemporary.txt исключается, как и каталог / somedir / temp .
* / * / темп * Исключить файлы и каталоги, начинающиеся с temp , из любого подкаталога, находящегося на два уровня ниже корня. Например, /somedir/subdir/ Contemporary.txt исключен.
темп? Исключить из корневого каталога файлы и каталоги, имена которых имеют односимвольное расширение temp .Например, / tempa и / tempb исключаются.

Сопоставление выполняется с помощью Go путь к файлу. правила соответствия. А шаг предварительной обработки удаляет начальные и конечные пробелы и устраняет . и .. элементов с использованием Go filepath.Clean. Линии пустые после предварительной обработки игнорируются.

Путь к файлу

Beyond Go. Соответствие правилам, Docker также поддерживает специальный строка подстановочного знака ** , которая соответствует любому количеству каталогов (включая нуль).Например, ** / *. Go исключит все файлы, заканчивающиеся на .go . которые находятся во всех каталогах, включая корень контекста сборки.

Строки начинающиеся с ! (восклицательный знак) можно использовать для исключения к исключениям. Ниже приведен пример файла .dockerignore , который использует этот механизм:

  * .md
! README.md
  

Все файлы уценки , кроме README.md , исключаются из контекста.

Размещение ! правил исключения влияет на поведение: последний строка .dockerignore , которая соответствует конкретному файлу, определяет включен он или исключен. Рассмотрим следующий пример:

  * .md
! README * .md
README-secret.md
  

В контекст не включены файлы уценки, кроме файлов README, кроме README-secret.md .

Теперь рассмотрим этот пример:

  *.мкр
README-secret.md
! README * .md
  

Включены все файлы README. Средняя линия не действует, потому что ! README * .md соответствует README-secret. md и идет последним.

Вы даже можете использовать файл .dockerignore , чтобы исключить файл Dockerfile и файлов .dockerignore . Эти файлы по-прежнему отправляются демону потому что они нужны ему для работы. Но инструкции ADD и COPY не копируйте их на изображение.

Наконец, вы можете указать, какие файлы включать в контекст, а не исключаемый. Для этого укажите * как первый шаблон, за которым следует один или несколько ! шаблонов исключений.

Примечание

По историческим причинам паттерн . игнорируется.

ИЗ

  ОТ [--platform = ]  [AS ]
  

или

  ОТ [--platform = ]  [: ] [AS ]
  

или

  ОТ [--platform = ]  [@ ] [AS ]
  

Инструкция FROM инициализирует новую стадию сборки и устанавливает Базовый образ для последующих инструкций. Таким образом, действительный Dockerfile должен начинаться с инструкции FROM . Изображение может быть любое действительное изображение - особенно легко начать с , вытащив образ из Публичные репозитории .

  • ARG - единственная инструкция, которая может предшествовать FROM в Dockerfile . См. Понимание того, как взаимодействуют ARG и FROM.
  • ИЗ может появляться несколько раз в одном файле Dockerfile от до создавать несколько образов или использовать один этап сборки как зависимость для другого.Просто запишите последний идентификатор изображения, выводимый коммитом перед каждым новым ИЗ инструкция. Каждая инструкция ИЗ очищает любое состояние, созданное предыдущим инструкции.
  • При желании можно дать имя новому этапу сборки, добавив Имя AS к ИЗ инструкция. Имя может использоваться в последующих ОТ и COPY --from = инструкций для обращения к образу, созданному на этом этапе.
  • Тег или дайджест Значения необязательны.Если вы опустите любой из них, Builder по умолчанию принимает последних тегов . Строитель возвращает ошибку, если не может найти значение тега .

Необязательный флаг --platform можно использовать для указания платформы образа. в случае, если ОТ ссылается на многоплатформенный образ. Например, linux / amd64 , linux / arm64 или windows / amd64 . По умолчанию целевая платформа сборки запрос используется. В значении этого флага можно использовать глобальные аргументы сборки, например автоматические платформенные ARG позволяет принудительно перейти на платформу собственной сборки ( --platform = $ BUILDPLATFORM ), и использовать его для кросс-компиляции на целевую платформу внутри сцены.

Понять, как взаимодействуют ARG и FROM

FROM инструкции поддерживают переменные, которые объявлены любыми ARG инструкции, которые появляются до первых ИЗ .

  ARG CODE_VERSION = последний
ИЗ базы: $ {CODE_VERSION}
CMD / код / ​​запуск приложения

ИЗ дополнительных услуг: $ {CODE_VERSION}
CMD / код / ​​дополнительные функции
  

ARG , объявленный перед FROM , находится вне стадии сборки, поэтому он не может использоваться ни в одной инструкции после ИЗ .Чтобы использовать значение по умолчанию ARG , объявленный перед первым FROM , использует инструкцию ARG без значение внутри стадии сборки:

  ARG VERSION = последняя
ОТ busybox: $ VERSION
ВЕРСИЯ ARG
ВЫПОЛНИТЬ echo $ VERSION> image_version
  

ЗАПУСК

RUN имеет 2 формы:

  • RUN <команда> (форма оболочки , команда запускается в оболочке, которая по умолчанию / bin / sh -c в Linux или cmd / S / C в Windows)
  • RUN ["исполняемый файл", "param1", "param2"] ( exec form)

Команда RUN будет выполнять любые команды на новом уровне поверх текущее изображение и зафиксируйте результаты. Полученное зафиксированное изображение будет используется для следующего шага в файле Dockerfile .

Наслоение RUN инструкций и генерация коммитов соответствует ядру концепции Docker, где коммиты дешевы, а контейнеры могут быть созданы из любой момент в истории изображения, как в системе управления версиями.

Форма exec позволяет избежать перестановки строк оболочки и RUN команды с использованием базового образа, не содержащего указанного исполняемого файла оболочки.

Оболочка по умолчанию для формы оболочки может быть изменена с помощью ОБОЛОЧКА команда.

В форме оболочки вы можете использовать \ (обратная косая черта), чтобы продолжить одиночный Инструкцию RUN на следующую строку. Например, рассмотрим эти две строки:

  RUN / bin / bash -c 'источник $ HOME / .bashrc; \
эхо $ HOME '
  

Вместе они эквивалентны одной строке:

  RUN / bin / bash -c 'source $ HOME /. bashrc; эхо $ HOME '
  

Чтобы использовать другую оболочку, кроме ‘/ bin / sh’, используйте форму exec , передаваемую в желаемый снаряд. Например:

  RUN ["/ bin / bash", "-c", "echo hello"]
  

Примечание

Форма exec анализируется как массив JSON, что означает, что вы должны заключать слова в двойные кавычки («), а не в одинарные кавычки («).

В отличие от формы оболочки , форма exec не вызывает командную оболочку.Это означает, что нормальной обработки оболочки не происходит. Например, RUN ["echo", "$ HOME"] не будет выполнять подстановку переменных в $ HOME . Если вам нужна обработка оболочки, используйте форму оболочки или выполните непосредственно оболочку, например: RUN ["sh", "-c", "echo $ HOME"] . При использовании формы exec и непосредственном выполнении оболочки, как в случае с форма оболочки, это оболочка, которая выполняет переменную среды расширение, а не докер.

Примечание

В форме JSON необходимо избегать обратной косой черты.Это особенно актуально в Windows, где обратная косая черта является разделителем пути. В противном случае следующая строка будет рассматриваться как форма оболочки из-за отсутствия действительный JSON, и неожиданный сбой:

  RUN ["c: \ windows \ system32 \ tasklist.exe"]
  

Правильный синтаксис для этого примера:

  RUN ["c: \\ windows \\ system32 \\ tasklist.exe"]
  

Кэш для команд RUN не становится недействительным автоматически во время следующая сборка.Кеш для инструкции типа RUN apt-get dist-upgrade -y будет повторно использован во время следующей сборки. В кэш для RUN инструкций можно сделать недействительным с помощью --no-cache флаг, например docker build --no-cache .

См. Dockerfile Best Practices руководство для получения дополнительной информации.

Кэш для инструкций RUN может быть аннулирован инструкциями ADD и COPY .

Известные проблемы (RUN)

  • Проблема 783 связана с файлом. проблемы с разрешениями, которые могут возникнуть при использовании файловой системы AUFS. Вы может заметить это при попытке, например, rm файла.

    Для систем с последней версией aufs (например, dirperm1 опция крепления может быть установлен), докер попытается исправить проблему автоматически, установив слои с опцией dirperm1 . Более подробно по варианту dirperm1 можно можно найти в aufs , справочная страница

    Если ваша система не поддерживает dirperm1 , проблема описывает обходной путь.

CMD

Инструкция CMD имеет три формы:

  • CMD ["исполняемый файл", "параметр1", "параметр2"] (форма exec , это предпочтительная форма)
  • CMD ["param1", "param2"] (как параметров по умолчанию для ENTRYPOINT )
  • CMD command param1 param2 (форма оболочки )

В файле Dockerfile может быть только одна инструкция CMD . Если вы укажете более одного CMD тогда только последний CMD вступит в силу.

Основная цель CMD - предоставить значения по умолчанию для выполняющейся контейнер. Эти значения по умолчанию могут включать исполняемый файл, или они могут не указывать исполняемый файл, и в этом случае вы должны указать ENTRYPOINT инструкция тоже.

Если CMD используется для предоставления аргументов по умолчанию для инструкции ENTRYPOINT , обе инструкции CMD и ENTRYPOINT должны быть указаны с JSON формат массива.

Примечание

Форма exec анализируется как массив JSON, что означает, что вы должны использовать двойные кавычки («) вокруг слов, а не одинарные кавычки (‘).

В отличие от формы оболочки , форма exec не вызывает командную оболочку. Это означает, что нормальной обработки оболочки не происходит. Например, CMD ["echo", "$ HOME"] не будет выполнять подстановку переменных в $ HOME . Если вам нужна обработка оболочки, используйте форму оболочки или выполните оболочка напрямую, например: CMD ["sh", "-c", "echo $ HOME"] .При использовании формы exec и непосредственном выполнении оболочки, как в случае с форма оболочки, это оболочка, которая выполняет переменную среды расширение, а не докер.

При использовании в форматах оболочки или exec инструкция CMD устанавливает команду для выполнения при запуске образа.

Если вы используете форму оболочки из CMD , то <команда> будет выполняться в / bin / sh -c :

  ОТ ubuntu
CMD echo "Это тест."| туалет -
  

Если вы хотите, чтобы запускал ваш без оболочки , вы должны выразите команду в виде массива JSON и укажите полный путь к исполняемому файлу. Эта форма массива является предпочтительным форматом CMD . Любые дополнительные параметры должны быть индивидуально выражены в виде строк в массиве:

  ОТ ubuntu
CMD ["/ usr / bin / wc", "- help"]
  

Если вы хотите, чтобы ваш контейнер запускал каждый раз один и тот же исполняемый файл, тогда вам следует рассмотреть возможность использования ENTRYPOINT в сочетании с CMD .Видеть ВХОД .

Если пользователь указывает аргументы для docker run , то они переопределят по умолчанию указано в CMD .

Примечание

Не путайте RUN с CMD . RUN фактически запускает команду и фиксирует результат; CMD ничего не выполняет во время сборки, но указывает предполагаемая команда для изображения.

ТАБЛИЧКА

  LABEL <ключ> = <значение> <ключ> = <значение> <ключ> = <значение>. ..
  

Инструкция LABEL добавляет метаданные к изображению. LABEL - это пара ключ-значение. Чтобы включить пробелы в значение LABEL , используйте кавычки и обратная косая черта, как при синтаксическом анализе командной строки. Несколько примеров использования:

  LABEL "com.example.vendor" = "ACME Incorporated"
LABEL com.example.label-with-value = "foo"
LABEL version = "1.0"
LABEL description = "Этот текст иллюстрирует \
что значения меток могут занимать несколько строк ".
  

Изображение может иметь более одной метки.Вы можете указать несколько меток на одна линия. До Docker 1.10 это уменьшало размер окончательного образа, но это уже не так. Вы по-прежнему можете указать несколько ярлыков в одной инструкции одним из следующих двух способов:

  LABEL multi.label1 = "value1" multi.label2 = "value2" other = "value3"
  
  LABEL multi.label1 = "значение1" \
      multi. label2 = "значение2" \
      другое = "значение3"
  

Метки, включенные в базовые или родительские изображения (изображения в строке FROM ), являются унаследовано вашим изображением.Если метка уже существует, но с другим значением, последнее примененное значение переопределяет любое ранее установленное значение.

Для просмотра меток изображения используйте команду docker image inspect . Вы можете использовать опция --format для отображения только меток;

  образ докера проверить --format = '' myimage
  
  {
  "com.example.vendor": "ACME Incorporated",
  "com.example.label-with-value": "foo",
  "версия": "1.0",
  "description": "Этот текст показывает, что значения меток могут занимать несколько строк.",
  "multi.label1": "значение1",
  "multi.label2": "значение2",
  "другое": "значение3"
}
  

ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ (устарело)

Инструкция MAINTAINER устанавливает поле Author сгенерированных изображений. Инструкция LABEL - гораздо более гибкая версия этого, и вы должны использовать вместо этого, поскольку он позволяет устанавливать любые требуемые метаданные, и их можно просмотреть легко, например с докером осмотрите . Чтобы установить метку, соответствующую MAINTAINER поле, которое вы можете использовать:

  LABEL keeper = "SvenDowideit @ home.org.au "
  

Это будет видно из docker inspect с другими метками.

ЭКСПОЗИЦИЯ

  EXPOSE <порт> [<порт> / <протокол> ...]
  

Инструкция EXPOSE сообщает Docker, что контейнер прослушивает указанные сетевые порты во время выполнения. Вы можете указать, прослушивает ли порт TCP или UDP, по умолчанию - TCP, если протокол не указан.

Инструкция EXPOSE фактически не публикует порт.Он функционирует как тип документации между человеком, который создает изображение, и человеком, который запускает контейнер, о том, какие порты предназначены для публикации. На самом деле опубликуйте порт при запуске контейнера, используйте флаг -p на docker run для публикации и сопоставления одного или нескольких портов или флага -P для публикации всех открытых порты и сопоставьте их с портами высокого порядка.

По умолчанию EXPOSE предполагает TCP. Вы также можете указать UDP:

Чтобы открыть как TCP, так и UDP, включите две строки:

  EXPOSE 80 / tcp
EXPOSE 80 / udp
  

В этом случае, если вы используете -P с docker run , порт будет открыт один раз для TCP и один раз для UDP.Помните, что -P использует эфемерный хост высокого порядка порт на хосте, поэтому порт не будет одинаковым для TCP и UDP.

Независимо от настроек EXPOSE , вы можете переопределить их во время выполнения, используя флаг -p . Например

  docker run -p 80: 80 / tcp -p 80: 80 / udp . ..
  

Чтобы настроить перенаправление портов в хост-системе, см. Использование флага -P. Команда docker network поддерживает создание сетей для связи между контейнеров без необходимости предоставлять или публиковать определенные порты, потому что подключенные к сети контейнеры могут связываться друг с другом через любые порт.Для получения подробной информации см. обзор этой функции.

ENV

Инструкция ENV устанавливает для переменной среды <ключ> значение <значение> . Это значение будет в окружении для всех последующих инструкций на этапе сборки и может быть заменен встроенным в многие тоже. Значение будет интерпретировано для других переменных среды, поэтому символы кавычек будут удалены, если они не экранированы. Подобно синтаксическому анализу командной строки, кавычки и обратные косые черты могут использоваться для включения пробелов в значения.

Пример:

  ENV MY_NAME = "Джон Доу"
ENV MY_DOG = Рекс \ Собака
ENV MY_CAT = пушистый
  

Команда ENV позволяет установить несколько переменных <ключ> = <значение> . .. за один раз, и приведенный ниже пример даст такие же чистые результаты в финальном изображение:

  ENV MY_NAME = "Джон Доу" MY_DOG = Рекс \ Собака \
    MY_CAT = пушистый
  

Переменные среды, установленные с помощью ENV , будут сохраняться при запуске контейнера. из полученного изображения.Вы можете просмотреть значения с помощью docker inspect и измените их, используя docker run --env = .

Сохранение переменной среды может вызвать непредвиденные побочные эффекты. Например, установка ENV DEBIAN_FRONTEND = noninteractive изменяет поведение apt-get , и может запутать пользователей вашего изображения.

Если переменная среды нужна только во время сборки, а не в финале изображение, рассмотрите возможность установки значения для одной команды:

  RUN DEBIAN_FRONTEND = неинтерактивный apt-get update && apt-get install -y...
  

Или используя ARG , который не сохраняется в окончательном образе:

  ARG DEBIAN_FRONTEND = не интерактивный
ЗАПУСТИТЬ apt-get update && apt-get install -y . ..
  

Альтернативный синтаксис

Инструкция ENV также допускает альтернативный синтаксис ENV <ключ> <значение> , исключая = . Например:

Этот синтаксис не позволяет устанавливать несколько переменных среды в одиночная ENV инструкция, и может сбивать с толку.Например, следующие устанавливает единственную переменную среды ( ONE ) со значением "TWO = THREE = world" :

Альтернативный синтаксис поддерживается для обратной совместимости, но не рекомендуется по причинам, указанным выше, и может быть удален в будущем выпуске.

ДОБАВИТЬ

ADD имеет две формы:

  ДОБАВИТЬ [--chown = <пользователь>: <группа>]  ... <самый лучший>
ДОБАВИТЬ [--chown = <пользователь>: <группа>] ["",... "<самый лучший>"]
  

Последняя форма требуется для путей, содержащих пробелы.

Примечание

Функция --chown поддерживается только в файлах Dockerfiles, используемых для сборки контейнеров Linux, и не будет работать с контейнерами Windows. Поскольку концепции владения пользователями и группами не переводить между Linux и Windows, использование / etc / passwd и / etc / group для преобразование имен пользователей и групп в идентификаторы ограничивает возможность использования этой функции для контейнеров на базе ОС Linux.

Инструкция ADD копирует новые файлы, каталоги или URL-адреса удаленных файлов из и добавляет их в файловую систему образа по пути .

Можно указать несколько ресурсов , но если они являются файлами или каталоги, их пути интерпретируются относительно источника контекст сборки.

Каждый может содержать подстановочные знаки, и сопоставление будет выполняться с использованием Go Путь файла. Правила матча. Например:

Чтобы добавить все файлы, начинающиеся с «hom»:

В примере ниже ? заменяется любым одиночным символом, например, «home.txt».

- это абсолютный путь или путь относительно WORKDIR , в который источник будет скопирован в целевой контейнер.

В приведенном ниже примере используется относительный путь и добавляется «test.txt» к / relativeDir / :

.
  ADD test.txt relativeDir /
  

В этом примере используется абсолютный путь и добавляется «test.txt» к / absoluteDir /

  ДОБАВИТЬ test.txt / absoluteDir /
  

При добавлении файлов или каталогов, содержащих специальные символы (например, [ и ] ), вам нужно избегать этих путей, следуя правилам Голанга, чтобы предотвратить их не рассматривать как соответствующий шаблон. Например, чтобы добавить файл с именем arr [0] . txt , используйте следующее;

Все новые файлы и каталоги создаются с UID и GID, равными 0, если только необязательный флаг --chown указывает имя пользователя, имя группы или UID / GID комбинация, чтобы запросить конкретное право собственности на добавленный контент.В формат флага --chown позволяет использовать строки имени пользователя и группы или прямые целочисленные UID и GID в любой комбинации. Предоставление имени пользователя без groupname или UID без GID будут использовать тот же числовой UID, что и GID. Если указано имя пользователя или группы, корневая файловая система контейнера Файлы / etc / passwd и / etc / group будут использоваться для выполнения перевода. от имени до целого UID или GID соответственно. Следующие примеры показывают допустимые определения для флага --chown :

  ADD --chown = 55: файлы mygroup * / somedir /
ДОБАВИТЬ --chown = bin файлы * / somedir /
ДОБАВИТЬ --chown = 1 файл * / somedir /
ДОБАВИТЬ --chown = 10: 11 файлов * / somedir /
  

Если корневая файловая система контейнера не содержит / etc / passwd или / etc / group файлов и имена пользователей или групп используются в --chown флаг, сборка завершится ошибкой при операции ADD . Использование числовых идентификаторов требует без поиска и не будет зависеть от содержимого корневой файловой системы контейнера.

В случае, когда - это URL-адрес удаленного файла, адресат будет имеют разрешения 600. Если удаленный файл, который извлекается, имеет HTTP Last-Modified header, будет использоваться метка времени из этого заголовка для установки mtime в конечном файле. Однако, как и любой другой файл обработано во время ADD , mtime не будет включено в определение от того, был ли изменен файл и должен ли обновляться кеш.

Примечание

При сборке путем передачи файла Dockerfile через STDIN (докер build - ), контекста сборки нет, поэтому Dockerfile может содержать только инструкцию ADD на основе URL. Вы также можете пройти сжатый архив через STDIN: (сборка докеров - tar.gz ), файл Dockerfile в корне архива и остальная часть Архив будет использоваться в качестве контекста сборки.

Если ваши файлы URL защищены с помощью аутентификации, вам необходимо использовать RUN wget , RUN curl или используйте другой инструмент из контейнера в качестве инструкции ADD не поддерживает аутентификацию.

Примечание

Первая обнаруженная инструкция ADD сделает кеш недействительным для всех следуя инструкциям Dockerfile, если содержимое имеет изменилось.Это включает аннулирование кеша для RUN инструкций. См. Dockerfile Best Practices. руководство - Использование кеша сборки для дополнительной информации.

ADD подчиняется следующим правилам:

  • Путь должен находиться в контексте сборки; вы не можете ADD . ./something / something , потому что первый шаг docker build - отправить контекстный каталог (и подкаталоги) в демон докера.

  • Если - это URL, а не заканчивается косой чертой в конце, то файл загружается с URL-адреса и копируется в .

  • Если - это URL, а оканчивается косой чертой в конце, то имя файла выводится из URL-адреса, и файл загружается в <самый старый> / <имя файла> . Например, ADD http: // example.com / foobar / будет создайте файл / foobar . URL-адрес должен иметь нетривиальный путь, чтобы в этом случае можно найти соответствующее имя файла ( http://example.com не будет работать).

  • Если - это каталог, копируется все содержимое каталога, включая метаданные файловой системы.

Примечание

Сам каталог не копируется, только его содержимое.

  • Если - это локальный tar-архив в распознанном формате сжатия (identity, gzip, bzip2 или xz), затем он распаковывается как каталог. Ресурсы из удаленного URL-адреса не распакованы . Когда каталог копируется или распакованный, он имеет то же поведение, что и tar -x , результатом является объединение:

    1. Все, что было на пути назначения и
    2. Содержимое исходного дерева, конфликты разрешены в пользу из «2.”По каждому файлу.

    Примечание

    Идентифицирован ли файл как распознанный формат сжатия или нет выполняется исключительно на основе содержимого файла, а не имени файла. Например, если пустой файл заканчивается на .tar.gz , это не будет будет распознан как сжатый файл, и не будет генерировать какие-либо сообщение об ошибке декомпрессии, скорее файл будет просто скопирован в пункт назначения.

  • Если - это файл любого другого типа, он копируется отдельно вместе с его метаданные. В этом случае, если заканчивается косой чертой /, будет считаться каталогом и будет записано содержимое по адресу / base () .

  • Если указано несколько ресурсов , либо напрямую, либо из-за использование подстановочного знака, тогда должен быть каталогом, и он должен заканчиваться на косая черта /.

  • Если не заканчивается косой чертой в конце, это будет считаться обычный файл, а содержимое будет записано в .

  • Если не существует, он создается вместе со всеми отсутствующими каталогами. на своем пути.

КОПИЯ

КОПИЯ имеет две формы:

  КОПИРОВАТЬ [--chown = <пользователь>: <группа>] ... <самый>
КОПИРОВАТЬ [--chown = <пользователь>: <группа>] ["", ... "<самый лучший>"]
  

Последняя форма требуется для путей, содержащих пробелы

Примечание

Функция --chown поддерживается только в файлах Dockerfiles, используемых для сборки контейнеров Linux, и не будет работать с контейнерами Windows. Поскольку концепции владения пользователями и группами не переводить между Linux и Windows, использование / etc / passwd и / etc / group для преобразование имен пользователей и групп в идентификаторы ограничивает возможность использования этой функции только для Контейнеры на базе ОС Linux.

Команда COPY копирует новые файлы или каталоги из и добавляет их в файловую систему контейнера по пути .

Можно указать несколько ресурсов , но пути к файлам и каталоги будут интерпретироваться как относящиеся к источнику контекста сборки.

Каждый может содержать подстановочные знаки, и сопоставление будет выполняться с использованием Go Путь файла.Правила матча. Например:

Чтобы добавить все файлы, начинающиеся с «hom»:

В примере ниже ? заменяется любым одиночным символом, например, «home.txt».

- это абсолютный путь или путь относительно WORKDIR , в который источник будет скопирован в целевой контейнер.

В приведенном ниже примере используется относительный путь и добавляется «test.txt» к / relativeDir / :

.
  COPY test.txt relativeDir /
  

В этом примере используется абсолютный путь и добавляется «test.txt» к / absoluteDir /

  КОПИРОВАТЬ test.txt / absoluteDir /
  

При копировании файлов или каталогов, содержащих специальные символы (например, [ и ] ), вам нужно избегать этих путей, следуя правилам Голанга, чтобы предотвратить их не рассматривать как соответствующий шаблон. Например, чтобы скопировать файл с именем arr [0] .txt , используйте следующее;

  КОПИЯ обр. [[] 0].txt / mydir /
  

Все новые файлы и каталоги создаются с UID и GID, равными 0, если только необязательный флаг --chown указывает имя пользователя, имя группы или UID / GID комбинация, чтобы запросить конкретное право собственности на скопированный контент. В формат флага --chown позволяет использовать строки имени пользователя и группы или прямые целочисленные UID и GID в любой комбинации. Предоставление имени пользователя без groupname или UID без GID будут использовать тот же числовой UID, что и GID.Если указано имя пользователя или группы, корневая файловая система контейнера Файлы / etc / passwd и / etc / group будут использоваться для выполнения перевода. от имени до целого UID или GID соответственно. Следующие примеры показывают допустимые определения для флага --chown :

  КОПИЯ --chown = 55: файлы mygroup * / somedir /
КОПИРОВАТЬ --chown = bin файлы * / somedir /
КОПИРОВАТЬ --chown = 1 файл * / somedir /
КОПИРОВАТЬ --chown = 10: 11 файлов * / somedir /
  

Если корневая файловая система контейнера не содержит / etc / passwd или / etc / group файлов и имена пользователей или групп используются в --chown флаг, сборка завершится ошибкой при операции COPY .Использование числовых идентификаторов требует нет поиска и не зависит от содержимого корневой файловой системы контейнера.

Примечание

Если вы собираете с использованием STDIN (сборка докеров - ), нет контекст сборки, поэтому COPY использовать нельзя.

Необязательно КОПИЯ принимает флаг --from = , который можно использовать для установки исходное местоположение на предыдущем этапе сборки (созданное с помощью FROM .. AS ) который будет использоваться вместо контекста сборки, отправленного пользователем.В случае сборки этап с указанным именем не может быть найден изображение с таким же именем попытался использовать вместо этого.

COPY подчиняется следующим правилам:

  • Путь должен находиться в контексте сборки; вы не можете COPY ../something / something , потому что первый шаг docker build - отправить контекстный каталог (и подкаталоги) в демон докера.

  • Если - это каталог, копируется все содержимое каталога, включая метаданные файловой системы.

Примечание

Сам каталог не копируется, только его содержимое.

  • Если - это файл любого другого типа, он копируется отдельно вместе с его метаданные. В этом случае, если заканчивается косой чертой /, будет считаться каталогом и будет записано содержимое по адресу / base () .

  • Если указано несколько ресурсов , либо напрямую, либо из-за использование подстановочного знака, тогда должен быть каталогом, и он должен заканчиваться на косая черта /.

  • Если не заканчивается косой чертой в конце, это будет считаться обычный файл, а содержимое будет записано в .

  • Если не существует, он создается вместе со всеми отсутствующими каталогами. на своем пути.

Примечание

Первая обнаруженная инструкция COPY сделает кеш недействительным для всех следуя инструкциям Dockerfile, если содержимое имеет изменилось. Это включает аннулирование кеша для RUN инструкций. См. Dockerfile Best Practices. руководство - Использование кеша сборки для дополнительной информации.

ВХОД

ENTRYPOINT имеет две формы:

Форма exec , которая является предпочтительной формой:

  ENTRYPOINT ["исполняемый файл", "параметр1", "параметр2"]
  

Оболочка форма:

  ENTRYPOINT команда param1 param2
  

ENTRYPOINT позволяет вам настроить контейнер, который будет работать как исполняемый файл.

Например, следующий запускает nginx с содержимым по умолчанию, прослушивая на порту 80:

  $ docker run -i -t --rm -p 80:80 nginx
  

Аргументы командной строки для docker run будут добавлены в конце концов элементы в exec формируют ENTRYPOINT , и переопределят все указанные элементы используя CMD . Это позволяет передавать аргументы в точку входа, то есть docker run -d передаст аргумент -d точке входа.Вы можете переопределить инструкцию ENTRYPOINT , используя команду docker run --entrypoint флаг.

Форма оболочки предотвращает использование аргументов командной строки CMD или run . используется, но имеет тот недостаток, что ваш ENTRYPOINT будет запускаться как подкоманда / bin / sh -c , которая не передает сигналы. Это означает, что исполняемый файл не будет PID контейнера 1 - и будет не получать сигналы Unix - поэтому ваш исполняемый файл не получит SIGTERM из docker stop .

Только последняя инструкция ENTRYPOINT в Dockerfile будет иметь эффект.

Exec form Пример ENTRYPOINT

Вы можете использовать форму exec из ENTRYPOINT для установки довольно стабильных команд по умолчанию. и аргументы, а затем используйте любую форму CMD для установки дополнительных значений по умолчанию, которые с большей вероятностью будут изменены.

  ОТ ubuntu
ENTRYPOINT ["верх", "-b"]
CMD ["-c"]
  

Когда вы запустите контейнер, вы увидите, что top - единственный процесс:

  $ docker run -it --rm --name test top -H

наверх - 08:25:00 до 7:27, пользователей 0, средняя загрузка: 0.00, 0,01, 0,05
Темы: всего 1, 1 запущен, 0 спит, 0 остановлен, 0 зомби
% ЦП: 0,1 мкс, 0,1 синг, 0,0 нi, 99,7 ид, 0,0 ват, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: всего 2056668, использовано 1616832, свободно 439836, буферов 99352
KiB Swap: всего 1441840, 0 используется, 1441840 бесплатно. 1324440 кэшированных Mem

  PID ПОЛЬЗОВАТЕЛЬ PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND
    1 корень 20 0 19744 2336 2080 R 0,0 0,1 0: 00,04 верх
  

Для дальнейшего изучения результата вы можете использовать docker exec :

  $ docker exec -it test ps aux

USER PID% CPU% MEM VSZ RSS TTY STAT ВРЕМЯ НАЧАЛА КОМАНДА
корень 1 2.6 0,1 19752 2352? Сс + 08:24 0:00 вверх -b -H
корень 7 0,0 0,1 15572 2164? R + 08:25 0:00 пс доп.
  

И вы можете изящно запросить завершение работы top с помощью docker stop test .

В следующем файле Dockerfile показано использование ENTRYPOINT для запуска Apache в передний план (т.е. как PID 1 ):

  ОТ debian: стабильный
ЗАПУСТИТЬ apt-get update && apt-get install -y --force-yes apache2
ВЫБРАТЬ 80 443
VOLUME ["/ var / www", "/ var / log / apache2", "/ etc / apache2"]
ENTRYPOINT ["/ usr / sbin / apache2ctl", "-D", "FOREGROUND"]
  

Если вам нужно написать стартовый сценарий для одного исполняемого файла, вы можете убедиться, что последний исполняемый файл получает сигналы Unix, используя exec и gosu команды:

  #! / Usr / bin / env bash
set -e

если ["$ 1" = 'postgres']; тогда
    chown -R postgres "$ PGDATA"

    если [-z "$ (ls -A" $ PGDATA ")"]; тогда
        gosu postgres initdb
    фи

    exec gosu postgres "$ @"
фи

exec "$ @"
  

Наконец, если вам нужно сделать дополнительную очистку (или связаться с другими контейнерами) при завершении работы или координируете более одного исполняемого файла, вам может потребоваться что сценарий ENTRYPOINT получает сигналы Unix, передает их, а затем работает еще:

  #! / Bin / sh
# Примечание: я написал это с помощью sh, поэтому он работает и в контейнере busybox

# ИСПОЛЬЗУЙТЕ ловушку, если вам нужно также выполнить ручную очистку после остановки службы,
# или нужно запустить несколько сервисов в одном контейнере
trap "эхо TRAPed signal" HUP INT QUIT TERM

# запустить службу в фоновом режиме здесь
/ usr / sbin / apachectl начало

echo "[нажмите клавишу ввода для выхода] или запустите 'docker stop '"
читать

# остановить обслуживание и очистить здесь
эхо "остановка Apache"
/ usr / sbin / apachectl стоп

echo "вышел из $ 0"
  

Если вы запустите этот образ с docker run -it --rm -p 80:80 --name test apache , затем вы можете проверить процессы контейнера с помощью docker exec или docker top , а затем попросите скрипт остановить Apache:

  $ docker exec -it test ps aux

USER PID% CPU% MEM VSZ RSS TTY STAT ВРЕМЯ НАЧАЛА КОМАНДА
корень 1 0.1 0,0 4448 692? Сс + 00:42 0:00 / bin / sh /run.sh 123 cmd cmd2
корень 19 0,0 0,2 71304 4440? Сс 00:42 0:00 / usr / sbin / apache2 -k start
www-data 20 0,2 0,2 ​​360468 6004? Сл 00:42 0:00 / usr / sbin / apache2 -k start
www-data 21 0,2 0,2 ​​360468 6000? Сл 00:42 0:00 / usr / sbin / apache2 -k start
корень 81 0,0 0,1 15572 2140? R + 00:44 0:00 пс доп.

$ docker top test

КОМАНДА ПОЛЬЗОВАТЕЛЯ PID
10035 root {run.ш} / bin / sh /run.sh 123 cmd cmd2
10054 корень / usr / sbin / apache2 -k start
10055 33 / usr / sbin / apache2 -k начало
10056 33 / usr / sbin / apache2 -k начало

$ / usr / bin / time docker stop test

контрольная работа
реальный 0 м 0,27 с
пользователь 0 м 0,03 с
sys 0m 0,03 с
  

Примечание

Вы можете изменить настройку ENTRYPOINT , используя --entrypoint , но это может установить только двоичный файл exec ( sh -c использоваться не будет).

Примечание

Форма exec анализируется как массив JSON, что означает, что вы должны заключать слова в двойные кавычки («), а не в одинарные кавычки («).

В отличие от формы оболочки , форма exec не вызывает командную оболочку. Это означает, что нормальной обработки оболочки не происходит. Например, ENTRYPOINT ["echo", "$ HOME"] не будет выполнять подстановку переменных в $ HOME .Если вам нужна обработка оболочки, используйте форму оболочки или выполните оболочку напрямую, например: ENTRYPOINT ["sh", "-c", "echo $ HOME"] . При использовании формы exec и непосредственном выполнении оболочки, как в случае с форма оболочки, это оболочка, которая выполняет переменную среды расширение, а не докер.

Форма оболочки Пример ENTRYPOINT

Вы можете указать простую строку для ENTRYPOINT , и она будет выполняться в / bin / sh -c .Эта форма будет использовать обработку оболочки для замены переменных среды оболочки, и будет игнорировать любые аргументы командной строки CMD или , запускаемые докером . Чтобы гарантировать, что docker stop будет сигнализировать о любом длительно работающем исполняемом файле ENTRYPOINT правильно, вам нужно не забыть запустить его с exec :

  ОТ ubuntu
ENTRYPOINT exec top -b
  

Когда вы запустите этот образ, вы увидите единственный процесс PID 1 :

  $ docker run -it --rm --name test top

Mem: 1704520K используется, 352148K бесплатно, 0K shrd, 0K бафф, 140368121167873K кэшировано
ЦП: 5% usr 0% sys 0% nic 94% idle 0% io 0% irq 0% sirq
Средняя нагрузка: 0.08 0,03 0,05 2/98 6
  PID PPID USER STAT VSZ% VSZ% CPU COMMAND
    1 0 корень R 3164 0% 0% top -b
  

Который аккуратно выходит на докер-остановку :

  $ / usr / bin / time docker stop test

контрольная работа
реальный 0 м 0,20 с
пользователь 0 м 0,02 с
sys 0m 0,04 с
  

Если вы забыли добавить exec в начало вашего ENTRYPOINT :

  ОТ ubuntu
ENTRYPOINT top -b
CMD --ignored-param1
  

Затем вы можете запустить его (присвоив ему имя для следующего шага):

  $ docker run -it --name test top --ignored-param2

Mem: 1704184K используется, 352484K бесплатно, 0K SHRD, 0K бафф, 140621524238337K кэшировано
ЦП: 9% usr 2% sys 0% nic 88% idle 0% io 0% irq 0% sirq
Средняя нагрузка: 0.01 0,02 0,05 2/101 7
  PID PPID USER STAT VSZ% VSZ% CPU COMMAND
    1 0 корень S 3168 0% 0% / bin / sh -c top -b cmd cmd2
    7 1 корень R 3164 0% 0% top -b
  

Из вывода top видно, что указанная ENTRYPOINT не является PID 1 .

Если вы затем запустите docker stop test , контейнер не выйдет правильно - stop команда будет принудительно отправить SIGKILL после тайм-аута:

  $ docker exec -it test ps aux

КОМАНДА ПОЛЬЗОВАТЕЛЯ PID
    1 корень / bin / sh -c top -b cmd cmd2
    7 корень верхний -b
    8 корневых ps aux

$ / usr / bin / time docker stop test

контрольная работа
реальный 0м 10.19 с
пользователь 0 м 0,04 с
sys 0m 0,03 с
  

Понять, как взаимодействуют CMD и ENTRYPOINT

Инструкции CMD и ENTRYPOINT определяют, какая команда выполняется при запуске контейнера. Есть несколько правил, описывающих их сотрудничество.

  1. Dockerfile должен указывать хотя бы одну из команд CMD или ENTRYPOINT .

  2. ENTRYPOINT должен быть определен при использовании контейнера в качестве исполняемого файла.

  3. CMD следует использовать как способ определения аргументов по умолчанию для команды ENTRYPOINT или для выполнения специальной команды в контейнере.

  4. CMD будет переопределено при запуске контейнера с альтернативными аргументами.

В таблице ниже показано, какая команда выполняется для различных комбинаций ENTRYPOINT / CMD :

№ ВХОДА ENTRYPOINT exec_entry p1_entry ENTRYPOINT [«exec_entry», «p1_entry»]
Нет CMD ошибка , недопустима / bin / sh -c exec_entry p1_entry exec_entry p1_entry
CMD [«exec_cmd», «p1_cmd»] exec_cmd p1_cmd / bin / sh -c exec_entry p1_entry exec_entry p1_entry exec_cmd p1_cmd
CMD [«p1_cmd», «p2_cmd»] p1_cmd p2_cmd / bin / sh -c exec_entry p1_entry exec_entry p1_entry p1_cmd p2_cmd
CMD exec_cmd p1_cmd / bin / sh -c exec_cmd p1_cmd / bin / sh -c exec_entry p1_entry exec_entry p1_entry / bin / sh -c exec_cmd p1_cmd

Примечание

Если CMD определяется из базового образа, установка ENTRYPOINT будет сбросить CMD на пустое значение.В этом сценарии CMD должен быть определен в текущее изображение должно иметь значение.

ОБЪЕМ

Инструкция VOLUME создает точку монтирования с указанным именем и отмечает, что он содержит внешние тома с собственного хоста или другого контейнеры. Значение может быть массивом JSON, VOLUME ["/ var / log /"] или обычным строка с несколькими аргументами, например VOLUME / var / log или VOLUME / var / log / var / db . Для получения дополнительной информации / примеров и инструкций по монтажу через Клиент Docker, см. общих каталогов в томах документация.

Команда docker run инициализирует вновь созданный том любыми данными. который существует в указанном месте в базовом образе. Например, рассмотрите следующий фрагмент Dockerfile:

  ОТ ubuntu
ЗАПУСК mkdir / myvol
RUN echo "hello world"> / myvol / приветствие
VOLUME / myvol
  

Этот файл Dockerfile приводит к созданию образа, который вызывает запуск докера в создайте новую точку монтирования по адресу / myvol и скопируйте файл приветствия во вновь созданный том.

Примечания к указанию томов

Помните о томах в Dockerfile .

  • Тома в контейнерах на базе Windows : при использовании контейнеров на базе Windows место назначения тома внутри контейнера должно быть одним из:

    • несуществующий или пустой каталог
    • привод, отличный от C:
  • Изменение громкости из Dockerfile : Если какие-либо шаги сборки изменят данные в томе после того, как они были объявлены, эти изменения будут отменены.

  • Форматирование JSON : список анализируется как массив JSON. Слова следует заключать в двойные кавычки ( "), а не в одинарные кавычки ( ').

  • Каталог хоста объявлен во время выполнения контейнера : Каталог хоста (точка монтирования) по своей природе зависит от хоста. Это для сохранения имиджа переносимость, поскольку не может быть гарантирована доступность данного каталога хоста на всех хостах.По этой причине вы не можете смонтировать каталог хоста из в Dockerfile. Инструкция VOLUME не поддерживает указание host-dir параметр. Вы должны указать точку монтирования при создании или запуске контейнера.

ПОЛЬЗОВАТЕЛЬ

или

Инструкция USER устанавливает имя пользователя (или UID) и, возможно, пользователя. группа (или GID) для использования при запуске образа и для любых RUN , CMD и ENTRYPOINT , которые следуют за ним в файле Dockerfile .

Обратите внимание, что при указании группы для пользователя у пользователя будет , только указанное членство в группе. Любое другое настроенное членство в группах будет проигнорировано.

Предупреждение

Если у пользователя нет основной группы, тогда изображение (или следующее инструкции) будет запускаться с корневой группой .

В Windows сначала необходимо создать пользователя, если это не встроенная учетная запись. Это можно сделать с помощью команды net user , вызываемой как часть файла Dockerfile.

  ОТ microsoft / windowsservercore
# Создать пользователя Windows в контейнере
RUN net user / добавить патрика
# Установите его для последующих команд
ПОЛЬЗОВАТЕЛЬ патрик
  

WORKDIR

Инструкция WORKDIR устанавливает рабочий каталог для любых RUN , CMD , ENTRYPOINT , COPY и ADD инструкции, которые следуют за ним в Dockerfile . Если WORKDIR не существует, он будет создан, даже если он не используется ни в одном последующая инструкция Dockerfile .

Инструкцию WORKDIR можно использовать несколько раз в файле Dockerfile . Если указан относительный путь, он будет относиться к пути предыдущего WORKDIR инструкция. Например:

  WORKDIR / a
WORKDIR b
WORKDIR c
RUN pwd
  

Результат последней команды pwd в этом файле Dockerfile будет / a / b / c .

Команда WORKDIR может разрешить переменные среды, ранее установленные с помощью ENV .Вы можете использовать только переменные среды, явно установленные в Dockerfile . Например:

  ENV DIRPATH = / путь
WORKDIR $ DIRPATH / $ DIRNAME
RUN pwd
  

Результат последней команды pwd в этом файле Dockerfile будет / путь / $ DIRNAME

ARG

  ARG <имя> [= <значение по умолчанию>]
  

Инструкция ARG определяет переменную, которую пользователи могут передавать во время сборки в построитель с помощью команды docker build с использованием --build-arg = флаг.Если пользователь указывает аргумент сборки, который не был определенный в Dockerfile, сборка выдает предупреждение.

  [Предупреждение] Один или несколько аргументов сборки [foo] не использовались.
  

Dockerfile может включать одну или несколько инструкций ARG . Например, это действительный файл Dockerfile:

  ОТ busybox
ARG user1
ARG buildno
# ...
  

Предупреждение:

Не рекомендуется использовать переменные времени сборки для передачи секретов, например ключи github, учетные данные пользователя и т. д.Значения переменных времени сборки видны любой пользователь образа с помощью команды docker history .

См. «Сборку образов с помощью BuildKit» раздел, чтобы узнать о безопасных способах использования секретов при создании изображений.

Значения по умолчанию

Команда ARG может дополнительно включать значение по умолчанию:

  ОТ busybox
ARG user1 = someuser
ARG buildno = 1
# ...
  

Если команда ARG имеет значение по умолчанию и если значение не передано во время сборки построитель использует значение по умолчанию.

Область применения

Определение переменной ARG вступает в силу со строки, на которой оно определено в Dockerfile не из использования аргумента в командной строке или в другом месте. Например, рассмотрим этот Dockerfile:

  ОТ busybox
ПОЛЬЗОВАТЕЛЬ $ {пользователь: -some_user}
Пользователь ARG
USER $ пользователь
# ...
  

Пользователь создает этот файл, позвонив:

  $ docker build --build-arg user = what_user.
  

USER в строке 2 оценивается как some_user , поскольку переменная user определена в следующая строка 3. ПОЛЬЗОВАТЕЛЬ в строке 4 оценивается как what_user как пользователь определено, и значение what_user было передано в командной строке. До его определения ARG инструкция, любое использование переменной приводит к пустой строке.

Инструкция ARG выходит за рамки в конце сборки этап, на котором это было определено. Чтобы использовать аргумент на нескольких этапах, каждый этап должен включить инструкцию ARG .

  ОТ busybox
НАСТРОЙКИ ARG
ЗАПУСТИТЬ ./ run / setup $ НАСТРОЙКИ

ОТ busybox
НАСТРОЙКИ ARG
RUN ./run/other $ SETTINGS
  

Использование переменных ARG

Вы можете использовать команду ARG или ENV , чтобы указать переменные, которые доступный для инструкции RUN . Переменные среды, определенные с помощью ENV инструкция всегда имеет приоритет над одноименной инструкцией ARG . Рассматривать этот Dockerfile с инструкциями ENV и ARG .

  ОТ ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER = v1.0.0
RUN echo $ CONT_IMG_VER
  

Тогда предположим, что этот образ создан с помощью этой команды:

  $ docker build --build-arg CONT_IMG_VER = v2.0.1.
  

В этом случае инструкция RUN использует v1.0.0 вместо настройки ARG передано пользователем: v2.0.1 Это поведение похоже на оболочку сценарий, в котором переменная с локальной областью видимости переопределяет переменные, переданные как аргументы или унаследованные от окружения с точки его определения.

Используя приведенный выше пример, но другую спецификацию ENV , вы можете создать больше полезные взаимодействия между ARG и ENV инструкции:

  ОТ ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER = $ {CONT_IMG_VER: -v1.0.0}
RUN echo $ CONT_IMG_VER
  

В отличие от инструкции ARG , значения ENV всегда сохраняются во встроенном образ. Рассмотрим сборку докеров без флага --build-arg :

В этом примере файла Dockerfile CONT_IMG_VER все еще сохраняется в образе, но его значение будет v1.0.0 , так как это значение по умолчанию установлено в строке 3 инструкцией ENV .

Метод расширения переменных в этом примере позволяет передавать аргументы из командной строки и сохраните их в окончательном изображении, используя ENV инструкция. Расширение переменных поддерживается только для ограниченного набора Инструкции Dockerfile.

Предопределенные группы ARG

Docker имеет набор предопределенных переменных ARG , которые можно использовать без соответствующая инструкция ARG в Dockerfile.

  • HTTP_PROXY
  • http_proxy
  • HTTPS_PROXY
  • https_proxy
  • FTP_PROXY
  • ftp_proxy
  • NO_PROXY
  • no_proxy

Чтобы использовать их, просто передайте их в командной строке с помощью флага:

  --build-arg <имя переменной> = <значение>
  

По умолчанию эти предопределенные переменные исключаются из вывода история докеров .Их исключение снижает риск случайной утечки. конфиденциальная информация аутентификации в переменной HTTP_PROXY .

Например, рассмотрите возможность создания следующего Dockerfile, используя --build-arg HTTP_PROXY = http: // user: [email protected]

  ОТ ubuntu
RUN echo "Hello World"
  

В этом случае значение переменной HTTP_PROXY недоступно в история докеров и не кешируется.Если бы вы изменили местоположение, и ваш прокси-сервер изменен на http: // user: [email protected] , последующий build не приводит к пропуску кеша.

Если вам нужно изменить это поведение, вы можете сделать это, добавив ARG заявление в Dockerfile следующим образом:

  ОТ ubuntu
ARG HTTP_PROXY
RUN echo "Hello World"
  

При создании этого файла Dockerfile HTTP_PROXY сохраняется в история докеров , и изменение его значения делает недействительным кеш сборки.

Автоматические платформенные ARG в глобальном масштабе

Эта функция доступна только при использовании серверной части BuildKit.

Docker предопределяет набор из переменных ARG с информацией о платформе узел, выполняющий сборку (платформа сборки), и на платформе результирующее изображение (целевая платформа). Целевая платформа может быть указана с помощью флаг --platform в сборке docker build .

Следующие переменные ARG устанавливаются автоматически:

  • TARGETPLATFORM - платформа результата сборки.Например, linux / amd64 , linux / arm / v7 , windows / amd64 .
  • TARGETOS - компонент ОС TARGETPLATFORM
  • TARGETARCH - компонент архитектуры TARGETPLATFORM
  • TARGETVARIANT - вариантный компонент TARGETPLATFORM
  • BUILDPLATFORM - платформа узла, выполняющего сборку.
  • BUILDOS - компонент ОС BUILDPLATFORM
  • BUILDARCH - компонент архитектуры BUILDPLATFORM
  • BUILDVARIANT - вариантный компонент BUILDPLATFORM

Эти аргументы определены в глобальной области, поэтому автоматически не доступны внутри этапов сборки или для команд RUN .Разоблачить одну из эти аргументы внутри стадии сборки переопределяют его без значения.

Например:

  ОТ альпийский
ЦЕЛЕВАЯ ПЛАТФОРМА ARG
RUN echo "Я создаю для $ TARGETPLATFORM"
  

Влияние на кеширование сборки

ARG Переменные не сохраняются в построенном образе, как переменные ENV . Однако переменные ARG действительно влияют на кеш сборки аналогичным образом. Если Dockerfile определяет переменную ARG , значение которой отличается от предыдущего build, то при первом использовании происходит «промах в кэше», а не при его определении.В в частности, все инструкции RUN , следующие за инструкцией ARG , используют ARG переменная неявно (как переменная среды), что может вызвать промах в кеше. Все предопределенные переменные ARG освобождаются от кэширования, если нет соответствие ARG оператору в Dockerfile .

Например, рассмотрим эти два файла Dockerfile:

  ОТ ubuntu
ARG CONT_IMG_VER
RUN echo $ CONT_IMG_VER
  
  ОТ ubuntu
ARG CONT_IMG_VER
RUN echo привет
  

Если вы укажете --build-arg CONT_IMG_VER = в командной строке, в обоих случаях спецификация в строке 2 не вызывает промаха кеша; строка 3 делает вызвать промах кеша. ARG CONT_IMG_VER вызывает идентификацию строки RUN аналогично запуску CONT_IMG_VER = echo hello , поэтому, если изменения, мы получаем промах кеша.

Рассмотрим другой пример в той же командной строке:

  ОТ ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER = $ CONT_IMG_VER
RUN echo $ CONT_IMG_VER
  

В этом примере промах кэша происходит в строке 3. Промах случается потому, что значение переменной в ENV ссылается на переменную ARG и это переменная изменяется через командную строку.В этом примере ENV команда заставляет изображение включать значение.

Если инструкция ENV переопределяет инструкцию ARG с тем же именем, например этот Dockerfile:

  ОТ ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER = привет
RUN echo $ CONT_IMG_VER
  

Строка 3 не вызывает промаха кеша, потому что значение CONT_IMG_VER является константа ( привет ). В результате переменные среды и значения, используемые в RUN (строка 4) не меняется между сборками.

СТРОИТЕЛЬСТВО

Команда ONBUILD добавляет к изображению команду trigger для выполняться позже, когда изображение используется в качестве основы для другая сборка. Триггер будет выполнен в контексте последующая сборка, как если бы она была вставлена ​​сразу после FROM в последующем файле Dockerfile .

Любая инструкция сборки может быть зарегистрирована как триггер.

Это полезно, если вы создаете изображение, которое будет использоваться в качестве основы для создания других образов, например среды сборки приложения или демон, который можно настроить в соответствии с настройками пользователя.

Например, если ваше изображение является повторно используемым построителем приложений Python, оно потребует, чтобы исходный код приложения был добавлен в конкретный каталог, и может потребоваться, чтобы сценарий сборки вызывал после тот. Вы не можете просто позвонить по телефону ADD и RUN сейчас, потому что вы еще не иметь доступ к исходному коду приложения, и он будет другим для каждая сборка приложения. Вы можете просто предоставить разработчикам приложений с шаблоном Dockerfile для копирования и вставки в свое приложение, но это неэффективно, подвержено ошибкам и сложно обновлять, потому что смешивается с кодом конкретного приложения.

Решение состоит в том, чтобы использовать ONBUILD для регистрации предварительных инструкций в запустить позже, на следующем этапе сборки.

Вот как это работает:

  1. Когда он встречает инструкцию ONBUILD , построитель добавляет запускать метаданные создаваемого изображения. Инструкция не влияет иным образом на текущую сборку.
  2. В конце сборки список всех триггеров сохраняется в манифест образа, под ключом OnBuild .Их можно проверить с помощью Докер проверяет команду .
  3. Позже образ может быть использован в качестве основы для новой сборки, используя ИЗ инструкция. В рамках обработки инструкции FROM , построитель нисходящего потока ищет триггеры ONBUILD и выполняет их в том же порядке, в котором они были зарегистрированы. Если какой-либо из триггеров сбой, команда FROM прерывается, что, в свою очередь, вызывает построить на провал. Если все триггеры выполнены успешно, инструкция FROM завершается, и сборка продолжается как обычно.
  4. Триггеры удаляются из окончательного изображения после выполнения. В Другими словами, они не наследуются «внуками».

Например, вы можете добавить что-то вроде этого:

  ДОБАВИТЬ ДОБАВИТЬ. / приложение / src
ONBUILD RUN / usr / local / bin / python-build --dir / app / src
  

Предупреждение

Цепочка инструкций ONBUILD с использованием ONBUILD ONBUILD не допускается.

Предупреждение

Команда ONBUILD не может запускать команды FROM или MAINTAINER .

СИГНАЛ ОСТАНОВА

Команда STOPSIGNAL устанавливает сигнал системного вызова, который будет отправлен в контейнер для выхода. Этот сигнал может быть допустимым числом без знака, которое соответствует позиции в таблице системных вызовов ядра, например 9, или имя сигнала в формате SIGNAME, например SIGKILL.

ЗДОРОВЬЕ

Инструкция HEALTHCHECK имеет две формы:

  • HEALTHCHECK [OPTIONS] Команда CMD (проверьте работоспособность контейнера, запустив команду внутри контейнера)
  • HEALTHCHECK NONE (отключить любую проверку работоспособности, унаследованную от базового образа)

Инструкция HEALTHCHECK сообщает Docker, как тестировать контейнер, чтобы проверить, что он все еще работает.Это может обнаружить такие случаи, как застревание веб-сервера в бесконечный цикл и неспособность обрабатывать новые соединения, даже если сервер процесс все еще продолжается.

Когда для контейнера задана проверка работоспособности, он имеет статус в в дополнение к его нормальному состоянию. Этот статус изначально равен , начиная с . Всякий раз, когда проверка работоспособности проходит, он становится исправным (в каком бы состоянии он ни находился ранее). После определенного количества последовательных отказов становится неработоспособным .

Опции, которые могут появиться перед CMD :

  • --interval = DURATION (по умолчанию: 30s )
  • --timeout = DURATION (по умолчанию: 30s )
  • --start-period = DURATION (по умолчанию: 0s )
  • --retries = N (по умолчанию: 3 )

Проверка работоспособности сначала запустится с интервалом через секунду после того, как контейнер начался, а затем снова интервал секунд после завершения каждой предыдущей проверки.

Если один запуск проверки занимает больше времени, чем , таймаут секунд, то проверка считается потерпевшим неудачу.

Требуется повторных попыток последовательный сбой проверки работоспособности контейнера считаться нездоровой .

начальный период provi

Как сохранить разные версии документа Word в одном файле

Последнее обновление Наталья Кудрявцева .

Когда вы работаете над одним и тем же документом со своими коллегами, вам может потребоваться доступ к предыдущим версиям этого документа, чтобы внести изменения или восстановить его. Одновременное использование OneDrive и Microsoft Word позволяет OneDrive размещать различных версий документов Word , так что вы можете легко извлечь нужный документ. В этой статье вы узнаете , как хранить разные версии документа Word в одном файле и извлекать их при необходимости .

Вы можете легко просматривать и извлекать предыдущие версии документа Word, когда ваши файлы хранятся в облачной службе хранения OneDrive , подключенной к вашему программному обеспечению Office. Если вы используете OneDrive, процесс прост.

Как включить историю версий в Office

Чтобы подключить программное обеспечение Office к OneDrive, выполните следующие действия:

Откройте Microsoft Word и создайте новый пустой документ. Нажмите кнопку Войти в систему в правом верхнем углу документа.Введите свой адрес электронной почты Microsoft или Office 365 и пароль для входа.

Поздравляем! Теперь вы можете автоматически сохранять несколько версий ваших документов.


Как сохранить разные версии документа Word

Чтобы сохранить несколько версий документа Word, выполните следующую процедуру:

Откройте Microsoft Word и создайте документ. Чтобы сохранить эту версию, нажмите Файл> Сохранить . Сохраните файл в папке OneDrive .

Вы можете сохранять этот документ сколько угодно раз.

Как просмотреть другую версию документа

Откройте документ Word и нажмите кнопку История версий в правом верхнем углу.

В столбце справа вы можете выбрать версию, которую должен просматривать или восстанавливать . Чтобы восстановить версию, нажмите Открыть версию> Восстановить .

Как сравнить разные версии одного документа

Чтобы сравнить разные версии документа Word, откройте его и щелкните История версий , откройте нужную версию и нажмите кнопку Сравнить в главном меню, чтобы увидеть различия между последней версией и выбранной.


Как получить доступ к истории версий в Интернете

Чтобы открывать разные версии документа Word, вы также можете использовать OneDrive в Интернете. Перейдите в папку, в которой вы сохранили файлы, щелкните правой кнопкой мыши на выбранном документе и прокрутите вниз до История версий . В новой вкладке вы увидите список различных версий документа, которые вы можете скачать или восстановить .

Фото - 123рф.com.

Номер социального страхования - что вам понадобится перед началом работы

3. Что вам потребуется перед подачей заявки

Важно

Необходимо предоставить оригиналов документов; Фотокопии не принимаются .

Список сокращений

SIN
Номер социального страхования
IRCC
Иммиграция, беженцы и гражданство Канады
CIC
Гражданство и иммиграция Канады
COPR
Подтверждение постоянного проживания

Требования к переводу

Если вы отправляете документ не на английском или французском языках, вы также должны предоставить :

  • перевод документа на английский или французский язык и
  • свидетельство или письменное показание под присягой, подписанное переводчиком

Если документ переводит сертифицированный переводчик, вы должны предоставить подтверждение.Свидетельство - это документ, подтверждающий, что перевод является достоверной и точной версией исходного текста. (Сертифицированный переводчик является членом провинциальной или территориальной организации письменных и устных переводчиков.)

Если документ переводит не сертифицированный переводчик, вы должны предоставить письменное показание. Аффидевит - это документ, подтверждающий, что перевод является достоверной и точной версией исходного текста. Переводчик должен подписать письменные показания перед уполномоченным по присяге или уполномоченным по принятию аффидевитов .(Уполномоченный по присяге или уполномоченный по сдаче показаний под присягой назначается провинцией или территорией.)

Примечание: Переводы членами семьи не принимаются . (Член семьи определяется как родитель, опекун, брат или сестра, супруг, бабушка и дедушка, ребенок, тетя, дядя, племянница, племянник или двоюродный брат.)

Чтобы определить, какие документы вы должны предоставить, обратитесь к одному из следующих разделов, который относится к вам:

Примечание: Непредоставление необходимой документации приведет к отклонению вашей заявки.

Вы претендуете на себя

Подача заявки онлайн

Если вы подаете заявление онлайн, вы должны предоставить следующие документы:

  • цифровая копия действительного первичного документа (вы должны предоставить обе стороны документа, если на каждой стороне есть идентификационная информация)
  • цифровая копия подлинного действующего вторичного документа
  • цифровая копия подтверждения адреса
  • цифровая копия оригинального действительного подтверждающего документа (применимо только в том случае, если имя в вашем основном документе отличается от имени в дополнительном документе или от имени в вашей онлайн-форме SIN )

Важно:

  • Если вы подаете заявку онлайн, цифровые копии ваших документов должны быть четкими и разборчивыми
  • Если вы хотите, чтобы письмо с подтверждением SIN было отправлено на адрес, отличный от вашего, вы должны подать заявку по почте

Примечание: для заявителей старше 12 лет, но не достигших совершеннолетия:

Те же требования к документам применяются к детям старше 12 лет, но не достигшим совершеннолетия, которые подают заявление на себя.Если ребенок не может предоставить необходимые документы, представитель должен подать заявление от имени ребенка. Чтобы узнать, какие документы необходимы для подачи заявления от имени ребенка, обратитесь к одному из следующих разделов:

Подача заявления по почте

Если вы подаете заявление по почте, вы должны предоставить следующие документы:

  • оригинал действующего первичного документа
  • заполненная и подписанная анкета SIN. Если вам не удается распечатать форму заявки, вы можете заказать ее по телефону:
    • 1-866-274-6627 (бесплатный номер) или
    • , если за пределами Канады, по телефону 1-506-548-7961 (взимается плата за междугороднюю связь)
  • оригинальный действительный подтверждающий документ (применяется только в том случае, если имя в вашем основном документе отличается от имени в вашей форме заявления SIN )

Личное обращение

Если вы подаете заявление лично, вы должны предоставить следующие документы:

  • оригинал действующего первичного документа
  • оригинал действующего вторичного документа (применяется только в том случае, если вы достигли совершеннолетия в вашей провинции или территории проживания)
  • оригинал действительного подтверждающего документа (применяется только в том случае, если имя в вашем основном документе отличается от имени в вашем дополнительном документе или от имени, которое вы хотите зарегистрировать в Регистре социального страхования)

Вы являетесь родителем или законным опекуном, подающим заявление от имени несовершеннолетнего

Подача заявки онлайн

Если вы подаете заявление онлайн, вы должны предоставить следующие документы:

  • цифровая копия действительного первичного документа ребенка (вы должны предоставить обе стороны документа, если на каждой стороне есть идентификационная информация)
  • цифровая копия оригинального действительного подтверждающего документа ребенка (применимо только в том случае, если имя в основном документе ребенка отличается от имени в онлайн-заявке SIN )
  • родитель или законный опекун: цифровая копия вашего действительного первичного документа (вы должны предоставить обе стороны документа, если на каждой стороне есть идентификационная информация)
  • родитель или законный опекун: цифровая копия вашего действительного вторичного документа
  • родитель или законный опекун: цифровая копия вашего адреса
  • родитель или законный опекун: цифровая копия вашего оригинального действительного подтверждающего документа (применимо только в том случае, если имя в вашем основном документе отличается от имени в дополнительном документе или от имени родителя или законного опекуна в онлайн-форме SIN )
  • Только законный опекун
  • : цифровая копия оригинала или заверенная копия документа, подтверждающего вашу законную опеку, выданная властями провинции или территории.В Квебеке приемлемым документом является нотариально заверенное завещание
  • .

Важно:

  • Если вы подаете заявку онлайн, цифровые копии ваших документов должны быть четкими и разборчивыми
  • Если вы хотите, чтобы письмо с подтверждением SIN было отправлено на адрес, отличный от вашего, вы должны подать заявку по почте

Подача заявления по почте

Если вы подаете заявление по почте, вы должны предоставить следующие документы:

  • оригинальный действительный первичный документ ребенка
  • заполненная и подписанная анкета SIN.Если вам не удается распечатать форму заявки, вы можете заказать ее по телефону:
    • 1-866-274-6627 (бесплатный номер) или
    • , если за пределами Канады, по телефону 1-506-548-7961 (взимается плата за междугороднюю связь)
  • оригинальный действительный подтверждающий документ ребенка (применяется только в том случае, если имя в основном документе ребенка отличается от имени в форме заявления SIN )
  • родитель или законный опекун: ваш подлинный действующий основной документ
  • родитель или законный опекун: ваш исходный действительный подтверждающий документ (применяется только в том случае, если имя в вашем основном документе отличается от имени родителя или законного опекуна в онлайн-форме SIN )
  • только законный опекун: оригинал или заверенная копия документа, подтверждающего ваше законное опекунство, выданного властями провинции или территории.В Квебеке нотариально заверенное завещание является приемлемым документом
  • .

Личное обращение

Если вы подаете заявление лично, вы должны предоставить следующие документы:

  • оригинальный действительный первичный документ ребенка
  • оригинальный действительный подтверждающий документ ребенка (применяется только в том случае, если имя в основном документе ребенка отличается от имени, которое вы хотите зарегистрировать в Регистре социального страхования)
  • родитель или законный опекун: ваш SIN или, если у вас нет SIN, ваш оригинальный действующий первичный документ
  • родитель или законный опекун: ваш оригинал действующего вторичного документа
  • родитель или законный опекун: ваш исходный действительный подтверждающий документ (применяется только в том случае, если имя в вашем основном документе отличается от имени во вторичном документе)
  • Только законный опекун
  • : оригинал или заверенная копия документа, подтверждающего вашу законную опеку, выданного властями провинции или территории.В Квебеке нотариально заверенное завещание является приемлемым документом
  • .

Вы являетесь законным представителем, подающим заявление от имени другого лица

Назначенные судом адвокаты или частные лица, а также сотрудники провинции или территории могут подавать заявления от имени другого лица.

Подача заявки онлайн

Если вы подаете заявление онлайн, вы должны предоставить следующие документы:

Важно:

  • Если вы подаете заявку онлайн, цифровые копии ваших документов должны быть четкими и разборчивыми
  • Если вы хотите, чтобы письмо с подтверждением SIN было отправлено на адрес, отличный от вашего, вы должны подать заявку по почте

Подача заявления по почте

Если вы подаете заявление по почте, вы должны предоставить следующие документы:

Личное обращение

Если вы подаете заявление лично, вы должны предоставить следующие документы:

Вы являетесь законным представителем имения, запрашивающим подтверждение SIN для умершего человека

Законный представитель имения может запросить SIN умершего человека.

Подача заявления по почте

Если вы подаете заявление по почте, вы должны предоставить следующие документы:

  • оригинал действующего первичного документа умершего
  • заполненная и подписанная анкета SIN. Если у вас нет возможности распечатать форму заявки, вы можете заказать ее по телефону:
    • 1-866-274-6627 (бесплатный номер) или
    • , если за пределами Канады, по телефону 1-506-548-7961 (взимается плата за междугороднюю связь)
  • оригинал действительного подтверждающего документа умершего (если имя в первичном документе умершего отличается от имени в анкете SIN )
  • свидетельство о смерти
  • законный представитель недвижимости: ваш подлинный действующий первичный документ
  • законный представитель наследства: оригинал или заверенная копия документа, подтверждающего, что вы имеете законное право представлять имущество

Личное обращение

Если вы подаете заявление лично, вы должны предоставить следующие документы:

  • оригинал действующего первичного документа умершего
  • оригинал действительного подтверждающего документа умершего (если имя в основном документе умершего отличается от имени в регистре социального страхования)
  • свидетельство о смерти
  • законный представитель имения: оригинал действующего первичного документа
  • законный представитель наследства: оригинал или заверенная копия документа, подтверждающего, что вы имеете законное право представлять имущество

Описание и примеры необходимых видов документов

В разделе:

Первичный документ

Первичный документ - это официальный документ, удостоверяющий вашу личность и статус в Канаде.

Важно: Если вы подаете заявление лично или по почте, вы должны предоставить свой оригинал основного документа ; Фотокопии не принимаются .

Если вы подаете заявку онлайн, цифровая копия вашего документа должна быть четкой и разборчивой. Вы должны предоставить обе стороны документа, если на каждой стороне есть идентификационная информация.

Если есть незначительные расхождения между информацией, которую вы предоставили в своем онлайн-заявлении, и информацией в том виде, в котором она представлена ​​в вашем основном документе, информация будет внесена в Реестр социального страхования так, как она указана в вашем основном документе.

Чтобы определить, какой первичный документ необходимо предоставить, обратитесь к соответствующему разделу ниже:

Граждане Канады должны предоставить 1 из следующих документов:

Примечание

  • Большинство оригиналов свидетельств о рождении и свидетельств о рождении приемлемы для получения SIN . Однако некоторые свидетельства о рождении, хотя и оригинальные документы, выданные агентством естественного движения населения, могут больше не считаться действительными в провинции, выдавшей свидетельства, или соответствовать требованиям по различным причинам.Служба Канады должна проверить документ, чтобы определить его действительность.
  • Service Canada не принимает квебекские документы, подтверждающие рождение, выданные до 1994 года.
  • Если у вас есть статус индейца в соответствии с Законом об индейцах и вы хотите зарегистрировать свой статус в своей записи SIN , вы должны предоставить свой основной документ и Свидетельство о статусе индейца, выданное правительством Канады.

Постоянные жители должны предоставить 1 из следующих документов:

  • Карта постоянного резидента , выданная IRCC или CIC
  • Подтверждение постоянного проживания ( COPR ) , выданное IRCC , вместе с проездным документом (например, заграничным паспортом) или альтернативным удостоверением личности с фотографией, выданным властями провинции или территории (например, водительским удостоверением личности). лицензия)

    Примечание: Если COPR используется в течение одного года после получения статуса постоянного жителя, это приемлемо.По истечении этого срока требуется карта постоянного жителя

  • Запись о посадке , выданная CIC до 28 июня 2002 г.
  • Подтверждение посадки , выданное IRCC или CIC , когда исходная запись о посадке или COPR недоступна (например, если она была утеряна). Этот документ приемлем только для изменения записи SIN или для получения подтверждения существующего SIN
  • .
  • Проверка статуса или Проверка статуса , выданная IRCC или CIC .Этот документ приемлем только для изменения записи SIN или для подтверждения существующего SIN

Временные жители должны предоставить 1 из следующих документов:

  • разрешение на работу , выданное IRCC или CIC
  • разрешение на учебу , выданное IRCC или CIC , и отвечает одному из следующих требований:
    • указывает на то, что владелец разрешения «может согласиться на работу» или «может работать» в Канаде
    • Номер
    • подтверждается письмом о «подтверждении работы за пределами кампуса», выданным IRCC или CIC до 11 февраля 2015 г.

      Примечание: Если вы не соответствуете ни одному из этих требований, свяжитесь с IRCC , чтобы проверить, имеете ли вы право подать заявку на измененное разрешение на учебу

  • запись посетителя , выданная IRCC или CIC , указывающая, что вы имеете право работать в Канаде
  • дипломатическое удостоверение личности и разрешение на работу , выданное Министерством иностранных дел, торговли и развития
Лица, проживающие за пределами Канады и не имеющие юридического статуса в Канаде

Лица, проживающие за пределами Канады, не являющиеся ни гражданами Канады, ни зарегистрированными индейцами с , не имеющими юридического статуса в Канаде , но имеющие право на получение пособия или пенсии правительства Канады, должны предоставить следующие оригиналы документов:

  • свидетельство о рождении выдано государственным органом страны вашего рождения.Если документ составлен не на английском или французском языках, см. Требования к переводу
  • .
  • письмо , подтверждающее право на пенсию или льготы по пенсионному плану Канады, страховке по старости или Régime des rentes du Québec

Вторичный документ

Дополнительный документ - это официальный документ, удостоверяющий вашу личность.

Дополнительный документ должен быть действительным и выдан правительством (федеральным, провинциальным или территориальным). В документе должна быть указана следующая информация:

  • юридическое имя (фамилия и имя) и
  • дата рождения

Примеры допустимых вторичных документов:

  • паспорт (канадский или иностранный)
  • провинциальное или территориальное удостоверение личности или водительские права
  • любой другой государственный идентификационный номер

Сопроводительный документ

Подтверждающий документ - это юридический документ, в котором указано имя, которое вы в настоящее время используете.Это необходимо, если имя в вашем основном документе отличается от того, которое вы используете в настоящее время, или отличается от имени во вторичном документе.

Примеры допустимых подтверждающих документов:

  • свидетельство о браке, запись о заключении брака или заявление о браке (или документ с аналогичным названием, в зависимости от органа, выдавшего его) для подтверждения вашей фамилии после заключения брака. Примечание: это не относится к жителям Квебека, вступившим в брак после 1 апреля 1981 года, независимо от того, где они были замужем.
  • указ о разводе, свидетельство о разводе или абсолютный указ , выданный в соответствии с судом (канадским или иностранным) для расторжения брака для подтверждения фамилии, запрошенной в записи SIN , когда она не отображается в первичной или вторичный документ
  • свидетельство о законном изменении имени или документ постановления суда , выданный в соответствии с законодательством об изменении названия провинции или территории
  • Постановление об усыновлении , подтвержденное канадским судом (применяется только к усыновлению в Канаде)
  • нотариальное свидетельство , также называемое нотариальное свидетельство об усыновлении , выданное страной происхождения ребенка, усыновленного за границей и используемое приемными родителями для выдачи SIN на канадское имя усыновленного ребенка
  • запрос на внесение изменений в отчет о посадке , выданный IRCC или CIC и используемый для внесения изменений в отчет о посадке или COPR

Подтверждение адреса

Доказательство адреса - это документ, выданный учреждением или организацией, который содержит следующую информацию:

  • имя заявителя (фамилия и имя) или, если подает заявление от имени другого лица, имя (фамилия и имя) его родителя, законного опекуна или законного представителя
  • адрес заявителя или, в случае подачи заявления от имени другого лица, адрес родителя, законного опекуна или законного представителя

Примечание: Корреспонденция из программы SIN , такая как предыдущее Подтверждение письма SIN или письмо с отказом, не принимается в качестве подтверждения адреса.

Внешняя сторона конверта не считается доказательством адреса.

Примеры приемлемых доказательств адреса:

  • письмо или документ от федерального, провинциального, территориального или иностранного правительства.
  • письмо или документ из финансового учреждения. Например:
    • выписка из банка
    • выписка по кредитной карте
    • договор или выписка об ипотеке
  • договор аренды или аренды жилого помещения
  • вексель.Например:
    • от оператора связи
    • у провайдера кабельного телевидения или
    • от поставщика коммунальных услуг
  • любой документ, выданный:
    • школа
    • колледж, или
    • университет
  • трудовой договор (должен содержать раздел, подтверждающий ваш почтовый адрес)
  • письмо от организации или учреждения, подтверждающее почтовый адрес заявителя.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *