Что значит окружение в программировании
Что значит окружение в программировании
Для того, чтобы посмотреть окружение, просто введите команду env без аргументов. В зависимости от конфигурации системы, вывод env может занять несколько экранов, поэтому лучше сделать так: Или так: Или так:
Переменные окружения могут формироваться как из заглавных, так и из строчных символов, однако исторически сложилось именовать их в верхнем регистре. Мы также не будем отступать от этого неписанного правила.
Помимо переменных окружения, командные оболочки, такие как bash располагают собственным набором пар ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ. Это переменные оболочки. Набор таких переменных называют окружением (или средой) оболочки. Эти переменные чем-то напоминают локальные (стековые) переменные в языке C. Они недоступны для других программ (в том числе и для env) и используются в основном в сценариях оболочки. Чтобы задать переменную оболочки, достаточно написать в командной строке ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ. Однако, при желании, можно включить локальную переменную оболочки в основное окружение. Для этого используется команда export: Можно сделать сразу так: Прежде, чем продолжать дальше, попробуйте поиграться с переменными окружения, чтобы лучше все понять. Выясните экспериментальным путем, чувствительны ли к регистру символов переменные окружения; можно ли использовать в качестве значений переменных окружения строки, содержащие пробелы; если можно, то как?
4.2. Массив environ
Теперь, когда мы разобрались, что такое окружение, самое время написать программу для взаимодействия с окружением. Чтобы показать, как это все работает, сначала изобретем велосипед.
В заголовочном файле unistd.h объявлен внешний двумерный массив environ: В этом массиве хранится копия окружения процесса. Точка.
А читать environ нам никто не запрещал. Напишем одноименную программу (environ), которой в качестве аргумента передается имя переменной. Программа будет проверять, существует ли эта переменная в окружении; и если существует, то каково ее значение. Как мы позже узнаем, это можно было бы сделать значительно проще. Но я предупредил: мы изобретаем велосипед. Вот эта программа: А вот Makefile для этой программы (если нужен): Проверяем:
В приведенном примере мы осуществили простой синтаксический анализ массива environ, так как переменные и значения представлены в нем в обычном виде (ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ). К счастью нам больше не придется осуществлять синтаксический разбор массива environ. О настоящем предназначении этого массива будет рассказано в главе, посвященной многозадачности.
4.3. Чтение окружения: getenv()
Функция эта работает очень просто: если в качестве аргумента указано имя существующей переменной окружения, то функция возвращает указатель на строку, содержащую значение этой переменной; если переменная отсутствует, возвращается NULL.
4.4. Запись окружения: setenv()
Пришла пора модифицировать окружение! Еще раз напоминаю: каждый процесс получает не доступ к окружению, а копию окружения родительского процесса (в нашем случае это командная оболочка). Чтобы добавить в окружение новую переменную или изменить существующую, используется функция setenv, объявленная в файле stdlib.h. Ниже приведен адаптированный прототип этой функции.
Если хотите узнать, что значит «адаптированный прототип», загляните в /usr/include/stdlib.h на объявления функций getenv() и setenv() и больше не спрашивайте 😉
Наша новая программа setenv читает из командной строки два аргумента: имя переменной и значение этой переменной. Если переменная не может быть установлена, выводится ошибка, если ошибки не произошло, выводится результат в формате ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ. Вот эта программа:
Изменяя константу FL_OVWR можно несколько изменить поведение программы по отношению к существующим переменным окружения. Еще раз напоминаю: у каждого процесса своя копия окружения, которая уничтожается при завершении процесса. Экспериментируйте!
4.5. Сырая модификация окружения: putenv()
У функции putenv() есть одна особенность: указатель на строку, переданный в качестве аргумента, становится частью окружения. Если в дальнейшем строка будет изменена, будет изменено и окружение. Это очень важный момент, о котором не следует забывать. Ниже приведен адаптированный прототип функции putenv:
Теперь напишем программу, использующую putenv(). Вот она:
Программа немного сложнее тех, что приводились ранее, поэтому разберем все по порядку. Сначала создаем для удобства функцию print_evar (PRINT Environment VARiable), которая будет отражать текущее состояние переменной окружения, переданной в качестве аргумента. В функции main() перво-наперво выделяем в куче (heap) память для буфера, в который будут помещаться запросы; заносим адрес буфера в query_str. Теперь формируем строку, и посылаем запрос в функцию putenv(). Здесь нет ничего необычного. Дальше идет демонстрация того, на чем я акцентировал внимание: простое изменение содержимого памяти по адресу, хранящемуся в query_str приводит к изменению окружения; это видно из вывода функции print_evar(). Наконец, вызываем putenv() со строкой, не содержащей символа ‘=’ (равно). Это запрос на удаление переменной из окружения. Функция print_evar() подтверждает это.
Хочу заметить, что putenv() поддерживается не всеми версиями Unix. Если нет крайней необходимости, лучше использовать setenv() для пополнения/модификации окружения.
4.6. Удаление переменной окружения: unsetenv()
Функция unsetenv(), объявленная в stdlib.h, удаляет переменную из окружения. Ниже приведен адаптированный прототип этой функции.
Прежде всего хочу обратить внимание на то, что раньше функция unsetenv() ничего не возращала (void). С выходом версии 2.2.2 библиотеки glibc (январь 2001 года) функция стала возвращать int.
В программе показан один из самых варварских способов подстроить код под версию библиотеки. Это сделано исключительно для демонстрации двух вариантов unsetenv(). Никогда не делайте так в реальных программах. Намного проще и дешевле (в плане времени), не получая ничего от unsetenv() проверить факт удаления переменной при помощи getenv().
4.7. Очистка окружения: clearenv()
Функция clearenv(), объявленная в заголовочном файле stdlib.h, используется крайне редко для полной очистки окружения. clearenv() поддерживается не всеми версиями Unix. Ниже приведен ее прототип.
При успешном завершении clearenv() возвращает нуль. В случае ошибки возвращается ненулевое значение.
В большинстве случаев вместо clearenv() можно использовать следующую инструкцию:
Окружения развёртывания программного обеспечения
Только что опубликовал в русской википедии перевод статьи Deployment environment.
Публикую этот перевод здесь также. Замечания и комментарии приветствуются.
В развёртывании программного обеспечения, окружение или ярус является компьютерной системой в которой компьютерная программа или компонент программного обеспечения развёртывается и выполняется. В простом случае, такое развёртывание и немедленное выполнение программы на той же машине, может выполнятся в единственном окружении, однако при промышленной разработке используется разделение на development окружение (‘окружение разрабочика’) (где делаются исходные изменения) и production окружение (которое используют конечные пользователи); часто с промежуточными этапами (‘stages’) посередине. Этот структурированный процесс управления релизами может иметь фазы deployment (rollout, ‘развёртывание’, ‘выкатка’), testing (‘тестирование’), и rollback (‘откат’) в случае проблем.
Окружения могут существенно отличаться в размерах: deployment окружение это обычно рабочая станция отдельного разработчика, в то время как production окружение может быть сетью множества географически разнесённых машин в случае с дата-центров, или виртуальными машинами в случае с облачными решениями. Код, данные и конфигурация могут быть развёрнуты паралельно, и нет необходимости связи с соответствующим ярусом — например, pre-production код может подсоединяться к production БД.
Архитектуры
Архитектуры развёртывания существенно разнятся, но в целом, ярусы начинаются с develpment (DEV) и заканчиваются production (PROD). Распространённой 4-х ярусной архитектурой является каскад ярусов deployment, testing, model, production (DEV, TEST, MODL, PROD) c деплоем софта на каждом ярусе по очереди. Другое распространённое окружение это Quality Control (QC), для приёмочного тестирования; песочница или экспериментальное окружение (EXP), для экспериментов не предназначенных для передачи в продакшен; и Disaster Recovery (‘аварийное восстановление’), для предоставления возможности немедленного отката в случае проблемы с продакшеном. Другой распространённой архитектурой является deployment, testing, acceptance and production (DTAP).
Такая разбивка в частности подходит для серверных программ, когда сервера работают в удаленных дата-центрах; для кода который работает на конечных устройствах пользователя, например приложений (apps) или клиентов, последний ярус обозначают как окружение пользователя (USER) или локальное окружение (LOCAL).
Точные определения и границы между окружениями варьируется — test может рассматриваться как часть dev, приёмка может рассматриваться как часть test, часть stage, или быть отдельной и так далее. Основные ярусы обрабатываются в определённом порядке, с новыми релизами при развёртывании (rolled out или pushed) на каждом. Ярусы experimental и recovery, если представлены, являются внешними к этому процессу — experimental релизы являются конечными, в то время как recovery являются обычно старыми или дублирующими версиями production, развёрнутыми после production. В случае проблем, в последнем случае можно сделать roll back к старому релизу, и большинство просто выкатывают старый релиз таким же способом как новый. Последний шаг, деплой в production («pushing to prod») самый чувствительный, т.к. здесь любые проблемы напрямую влияют на пользователя. По этой причине это часто управляется по разному, но как минимум мониторится более тщательно, и в некоторых случаях имеется фаза отката или простого переключения. Лучше всего избегать названия вроде Quality Assurance (QA); QA не означает тестирование софта. Тестирование важно, но это отличается от QA.
Иногда развёртывание выполняется вне обычного процесса, главным образом для предоставления срочных или небольших изменений, без необходимости полного релиза. Это может быть один патч, большой service pack или небольшой hotfix.
Окружения могут быть очень разных размеров: разработка обычно идёт на индивидуальных машинах разработчиков (хотя это могут быть тысячи разработчиков), в то время как продакшеном могут быть тысячи географически распределённых машин; тестирование и QC может быть маленьгим и большим, зависеть от предоставленных ресурсов, а staging может варьироваться от единичной машины (подобно canary) до точных дубликатов продакшена.
Окружения
Local
Development/Thunk
Сервер разработки выступающий как песочница где разработчик может выполнить unit-тестирование
Integration
Основа для построения CI, или для тестирования сайд-эффектов разработчиком
Testing/Test/QC/Internal Acceptance
Окружение в котором выполняется тестирование интерфейса. Команда контроля качества проверяет что новый код не будет иметь влияния на существующую функциональность системы после деплоя нового кода в тестовое окружение.
Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo
Production/Live
Серверы конечных пользователей/клиентов
Окружение разработчика
Окружение разработчика (dev) является окружением в котором софт разрабатывается, это часто просто компьютер разработчика. Это отличается от конечной целевой среды некоторыми вещами — цель может не быть стационарным компьютером (это может быть смартфон, встроенная система, самоуправляемый транспорт датацентра и т.д.), и даже если это стационарный компьютер, окружение разработчика будет включать инструменты разработчика например компилятор, IDE, различные или дополнительные версии библиотек и вспомогательного софта, и т.д., что не представлено в пользовательском окружении.
В контексте управления ревизиями, особенно при участии множества разработчиков, проводятся более тонкие различия: разработчик имеет рабочую копию исходного текста на своей машине, и изменения вносятся в репозиторий, будучи закомиченными либо в «стволе», либо в ветке, в зависимости от методологии разработки. Окружение на отдельной рабочей станции, на которой изменения отработаны и опробованы, может называться локальным окружением или песочницей. Сборка копии исходного кода репозитория в чистом окружении является отдельным этапом интеграции (интеграция разрозненных изменений), и это окружение может называться интеграционным окружением или окружением разработчика; при непрерывной интеграции это делается часто, так же часто, как и для каждой ревизии. Понятие уровня исходного кода звучащее как «фиксация (коммит) изменения в репозитории» с последующей сборкой «ствола» или ветки — соответствует переходу от локального (индивидуального окружения разработчика) к интеграции (чистой сборке); плохой релиз на этом этапе означает, что изменение сломало сборку, а откат релиза соответствует либо откату всех сделанных изменений, либо отмене только ломающего изменения, если это возможно.
Тестовое окружение
Цель тестового окружения состоит в том, чтобы позволить людям, проводящим тестирование, пропускать новый и измененный код либо через автоматизированные проверки, либо через неавтоматизированные методы. После того, как разработчик пропускает новый код и конфигурации через модульное тестирование в среде разработки, код переносится в одну или несколько тестовых сред. После неудачи теста тестовая среда может удалить ошибочный код из тестовых платформ, связаться с ответственным разработчиком и предоставить детальные журналы тестирования и результаты. Если все тесты пройдут, тестовая среда или фреймворк непрерывной интеграции, контролирующий тесты, может автоматически перенести код в следующую среду развертывания.
Различные типы тестирования предполагают различные типы тестовых сред, некоторые или все из которых могут быть виртуализированы для обеспечения быстрого параллельного тестирования. Например, автоматизированные тесты пользовательского интерфейса могут выполняться на нескольких виртуальных операционных системах и дисплеях (реальных или виртуальных). Для проведения тестов производительности может потребоваться нормализованная базовая конфигурация аппаратного обеспечения, чтобы результаты тестов производительности можно было сравнивать с течением времени. Тестирование на доступность или устойчивость может основываться на симуляторах отказов в виртуальных аппаратных средствах и виртуальных сетях.
Тесты могут быть последовательными (один за другим) или параллельными (для некоторых или всех сразу), в зависимости от сложности тестовой среды. Важной целью agile и других высокопроизводительных практик разработки программного обеспечения является сокращение времени от разработки или предоставления программного обеспечения до его поставки в продакшен. Высокоавтоматизированные и распараллеленные тестовые среды вносят важный вклад в быструю разработку программного обеспечения.
Staging
Stage или stage-окружение — это среда для тестирования, которая в точности похожа на продакшен-окружение. Она стремится как можно точнее отразить реальное продакшен-окружение и может подключаться к другим продакшен-сервисам и данным, таким как базы данных. Например, серверы будут работать на удаленных машинах, а не локально (как на рабочей станции разработчика во время разработки, или на одной тестовой машине во время тестирования), чтобы проверить влияние сети на систему.
Основное назначение stage-окружения заключается в тестировании всех сценариев установки/конфигурации/перемещения скриптов и процедур, прежде чем они будут применены в продакшен-окружении. Это гарантирует, что все существенные и незначительные обновления продакшен-окружения будут завершены качественно, без ошибок и в минимальные сроки.
Другим важным использованием stage-окружения является тестирование производительности, в частности нагрузочное тестирование, так как это часто чувствительно для окружения.
Stage-окружение также используется некоторыми организациями для предварительного просмотра новых функций и их отбора заказчиками или для утверждения интеграции с работающими версиями внешних зависимостей.
Продакшен-окружение
Продакшен-окружение также известно как live (в частности в применении к серверам) так как это окружение, с которым непосредственно взаимодействуют пользователи.
Развертывание в производственной среде является наиболее чувствительным шагом; это может осуществляться путем непосредственного развертывания нового кода (перезаписывания старого кода, так что только одна копия представлена в один момент времени), или путем развертывания изменения конфигурации. Это может принимать различные формы: параллельное развертывание новой версии кода и переключение на неё с изменением конфигурации; развертывание новой версии кода рядом со старым с соответствующим «флагом нового функционала», и последующее переключение на новую версию с изменением конфигурации, которая выполнит переключение этого «флага»; или развертывание отдельных серверов (один выполняет старый код, другой — новый) с перенаправлением трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Всё это, в свою очередь, может быть применено одновременно или выборочно, и на разных этапах.
Развертывание новой версии обычно требует перезапуска, если только нет возможности горячего переключения, и поэтому требует либо прерывания обслуживания (обычно это пользовательское ПО, когда приложения должны быть перезагружены), либо дублирования — постепенного перезапуска экземпляров «за спиной» у балансировщика нагрузки, либо заблаговременного запуска новых серверов с последующим простым перенаправлением трафика на новые сервера.
При выкатке нового релиза в продакшен, вместо немедленного развертывания для всех экземпляров или пользователей, его можно сначала развернуть на одном экземпляре или для части пользователей, а затем уже либо развернуть для всех экземпляров, либо поэтапно по фазам, чтобы оперативно отлавливать возникающие проблемы. Это похоже на staging, за исключением того, что делается в продакшене, и по аналогии с добычей угля называется canary release. Это добавляет сложности если несколько релизов запускаются одновременно, и, поэтому их обычно стараются делать быстро, чтобы избежать проблем совместимости.
Окружение — Введение в программирование
Важное примечание
Изначально в начале конспекта и урока речь шла о глобальном и локальном окружении, но объяснялась фактически глобальная и локальная область видимости. В видео эта тема до сих пор называется «глобальное и локальное окружение», текстовая версия урока исправлена.
Прежде, чем приступить к уроку, разберёмся с терминологией:
Путаница возникает ещё потому, что в разделе про Область видимости мы смотрим на примеры, которые работают по правилу «лексическая область видимости». От этого никуда не деться, так как язык JavaScript работает именно так.
Транскрипт урока
Часть I. Окружение
Давайте поговорим об окружении. Наша планета огромна, но мы все делим её. Если вы построите химический завод, неплохо бы изолировать его от окружающего мира, чтобы то, что в нём происходит оставалось внутри. Вы можете сказать, что в этом здании своё окружение, микроклимат, изолированный от внешней окружающей среды. В программировании такая изоляция называется областью видимости.
Ваша программа имеет подобную структуру по похожим причинам. То, что вы создаёте снаружи — снаружи функций, инструкций if, циклов и других блоков кода — находится во внешней, глобальной области видимости.
У нас нет доступа к x снаружи, как будто её там не существует:
console.log вызывается в глобальном окружении, а x не задан в этом глобальном окружении. Поэтому мы получаем Reference Error.
Мы можем задать x глобально:
Теперь существует глобальный x и его значение было выведено на экран, но локальный x внутри функции multiplier по-прежнему виден только внутри этой функции. Эти два x не имеют ничего общего друг с другом, они находятся в разных областях видимости. Они не схлопываются в одно целое, несмотря на то, что у них одно и то же имя.
Любой блок кода между фигурными скобками имеет локальную область видимости. Вот пример с блоком if :
Ок, локальное не доступно снаружи. Но глобальное доступно везде. Даже внутри чего-то? Да!
Хоть это и заманчиво всё помещать в глобальную область видимости и забыть о сложностях областей видимости — это ужасная практика. Глобальные переменные делают ваш код невероятно хрупким. В таком случае что угодно может сломать что угодно. Поэтому избегайте глобальной области видимости, храните вещи там, где им место.
Часть II. Лексическая область видимости
Взгляните на эту программу:
Весь этот кусок кода мог бы быть внутри другой функции, и ещё внутри другой функции. И если бы b не нашлась здесь, JavaScript продолжил бы искать b за пределами функции, слой за слоем.
Заметьте, что a = 7 не затронула вычисления, a была найдена внутри, поэтому внешняя a не сыграла роли.
Этот механизм называется лексической областью видимости. Область видимости любого компонента определяется местом расположения этого компонента внутри кода. И вложенные блоки имеют доступ к их внешним областям видимости.
Часть III. Замыкания
Большинство языков программирования имеют что-то вроде области видимости или окружения, и этот механизм позволяет существовать замыканиям. Замыкание — это всего лишь модное название функции, которая запоминает внешние штуки, используемые внутри.
Перед тем, как мы продолжим, давайте вспомним, как функции создаются и используются:
f — довольно бесполезная функция, она всегда возвращает 0. Весь этот набор состоит из двух частей: константы и самой функции.
Мы использовали аналогию в предыдущих уроках: константы как листы бумаги — имя на одной стороне, значение на другой. Следовательно, f — лист бумаги с f на одной стороне и описанием запускаемой функции на другой.
Когда вы вызываете эту функцию, вот так:
… создаётся новый ящик, основываясь на описании на этом листе бумаги.
Ок, вернёмся к замыканиям. Рассмотрим следующий код:
Это может выглядеть как JavaScript-фокус, но замыкания, когда их используют разумно, могут сделать код приятней, чище и проще для чтения. И сама идея возврата функций тем же способом, которым можно возвращать числа и строки, даёт больше возможностей и гибкости.
Вы заметите, как часто эти идеи используются в программировании, и мы рассмотрим их мощь в следующих курсах.
Выводы
Глобальная против локальной
Локальные константы и переменные не видимы снаружи их области видимости:
Но если x представлен глобально, то он доступен:
Возможен доступ к внешней области видимости:
Лексическая область видимости
JavaScript пытается найти значение в текущем окружении. Но значение не находится и JavaScript выходит наружу, на один уровень за попытку, пока не найдёт значение или не поймет, что значение невозможно найти.
Замыкания
Это замыкание: сочетание функции и окружения, где она была заявлена.
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Нашли опечатку или неточность?
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Что-то не получается или материал кажется сложным?
Загляните в раздел «Обсуждение»:
Об обучении на Хекслете
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Рабочее окружение
Настройка рабочего окружения — не такое простое занятие, как может показаться на первый взгляд. Обычно начинающие разработчики (и не только) устанавливают проект и его зависимости прямо на ту систему, где они работают. Этот подход обладает рядом недостатков.
Очень важно то, что в отличие от просто виртуализации, когда вы запускаете операционную систему, как программу, и полностью работаете внутри нее, вагрант подразумевает только консольный доступ к виртуальной машине. Сама разработка при этом происходит на хост машине. По сути, вагрант используется как способ «запустить код в изолированном окружении», а не как способ разработки. По этой причине боксы, которые используются внутри вагранта, не имеют графического интерфейса.
Кроме этого вагрант из коробки предоставляет множество полезных функций, которые вам пришлось бы руками настраивать используя виртуализацию напрямую. Из ключевых это:
Единый реестр боксов. Вам нужно только указать правильный, а вагрант сам его ставит, настраивает и запускает. Автоматический шаринг директории запуска (обычно это директория с проектом) с виртуальной машиной, то есть код автоматически синхронизируется между хост ОС и гостевой ОС; Легкая настройка проброса портов. Например, вы стартуете сервер внутри вагранта (виртуальной машины), а доступ к нему имеете снаружи.
Чтобы начать работу с Vagrant, сначала необходимо скачать и установить одну из систем виртуализации, например, VirtualBox. Дальше нужно установить сам Vagrant. Установщик можно найти на этой странице https://www.vagrantup.com/downloads.html.
Далее, зайдите в тот проект, для которого вы будете создавать рабочее окружение и выполните там команду:
Следующая команда запускает виртуальную машину и проводит базовую конфигурацию.
Теперь ваша виртуальная машина запущена и готова к использованию. Чтобы подключиться, наберите:
После выполнения этой команды мы оказываемся внутри виртуальной машины с установленной на нее Ubuntu. Вагрант предусмотрительно подключил вашу директорию с проектом к виртуальной машине. Найти ее можно в директории /vagrant внутри виртуальной машины. Все изменения, которые вы делаете изнутри наружу и наоборот, синхронизируются.
Еще одной крайне полезной функцией вагранта является проброс портов. Пример:
Теперь все, что запущено на гостевой операционной системе на порту 80, доступно на хост системе на порту 8080. Можно добавить сколько угодно таких пробросов.
Кроме этого, у вагранта есть полезная функциональность под названием Provisioning. Она позволяет интегрироваться с большим количеством систем для управления конфигурацией. Для настройки операционной системы с помощью Ansible достаточно выполнить следующие шаги:
Написать плейбук. Включить provisioning.