Тогда заходите не с того конца. Есть же прекрасные штуки вроде guacamole (если нужен доступ к виртуалке), а для инженеров мы вообще разработали скрипт на python, который не позволял им управлять "не своими" виртуальными машинами (хотя пол капотом были все те же стандартные вызовы libvirt). Но это только если сами строите свой виртуальный хостинг с нуля. Да и то тогда все равно правильно начать с каких-либо готовых решений вроде opennebula
А потом кто-то случайно назначил неверные права и пользователь получил возможность смотреть куда ему не надо. "Запесочить" пользователя иногда действительно имеет смысл. Например, в особых продуктивных средах.
Это не нужно, т.к. гитлаб раннер ВСЕГДА скачивает все содержимое репозитория (регулируется отдельным параметром в gitlab-ci.yml). Поэтому второй раз скачивать ничего не надо )
нет, извне = снаружи хоста, а вот внутри докер сети свои правила (обращаемся по имени сервиса - т.е. через внутренний ДНС докера, и порт берем как "обычно" у сервиса, а не тот, который пробросили)
Принципиально - почему нет? Андроид основан на линуксе, причем уже в 6-м Андроиде ядро 3.4.0. Докеру, конечно, желательно поновее, т.к. он базируется на определенных технологиях из ядра.
Либо можно свести задачу, как выше рекомендовали, к установке линукса на андроид. Будет Линукс - будет докер.
Но вопрос в практической целесообразности этого упражнения. На телефоне все равно эффективно разрабатывать не получится...
Такое может быть по разным причинам. Начиная от того, что конкретный узел попал в бан РКН и именно докеру не повезло получить забаненный айпишник, а ещё совсем не обязательно, что внутри контейнера будет тот же днс сервер, что и на хосте. При определенном неудачном стечении обстоятельств docker фаллбечится к 8.8.8.8, что очень весело в Корп среде. Поэтому остаётся - только привести более полные логи происходящего и делать более подробную отладку (nslookup, dig, curl... на недоступный ресурс)
Самое простое - взять готовый контейнер (зачеркнуто) образ типа laradock и в него добавить python. По поводу alpine - точно уверены ? Это далеко не беспроблемный дистрибутив. https://habr.com/ru/post/486202/
Никак. Для начала - надо проработать модель рисков. Ну, скажем - какая беда от того, что этот файл будет виден владельцам сервера? Касательно того что можно делать - например, шифровать файл при записи на диск, ключ хранить где-то снаружи - но тогда все равно при должной квалификации можно (при физическом доступе к серверу, конечно) разобрать программу, осознать ее алгоритм и расшифровать данные.
Если хотите обезопаситься от потери данных - надо шифровать, класть в архив и заливать на какое-нибудь внешнее файловое хранилище. Тогда всегда можно будет откатиться к определенной версии БД
Насчет слэшей интересная история, потому что краткий гуглеж показал, что как минимум два ТФТП сервера дают именно обратные слэши и через ключ реестра переключаются в режим с правильными слэшами
Насколько я помню, все интернет протоколы (включая tftp) работают с прямым слэшом, а не с обратным. Если так, то ответ - никак. И нужно искать другое решение проблемы (какой, кстати?)
Все необходимые файлы можно скачать на том же ноуте под виндой (или любом другом устройстве м доступом в интернет), а затем перенести на Линукс через флэшку, например.
Все правильно. Потому что тег не может быть одновременно и на мастере, и на другой ветке - он вообще на коммите. Т.е. по сути особой разницы между веткой (бранчом) и тегом нет - это некие перемещаемые указатели внутри структуры дерева коммитов. Почему в CI_COMMIT_BRANCH нет ветки - это как раз это и объясняет, т.к. нельзя гарантированно определить к какой именно ветке относится конкретный коммит, если их более двух. А триггер сработал именно по сборке тега.... Сложный вопрос как поступить правильно, но выглядит будто у вас процесс изначально неправильно не спроектирован. А еще масла в огонь подливает то, что gitlab стягивает репозиторий в режиме detached......
На самом деле в гитлабе есть возможность заархивировать репозитории пользователя или передать их другому пользователю, прежде чем его удалять (ну, как бы логично - возможны разные воркфлоу)
