Size: a a a

2020 February 08

GG

George Gaál in DevOps
MAdMAx
ну опять же от задачи зависит конечно.
если надо взять файлик и распарсить его - то лучше петон
а если надо настроить удаленную машину, установить там ПО, собрать че-нить и т.д., то петоний мимо.
powershell вполне ок справляется )
у esxi кстати отличное расширение именно на powershell
если надо настроить удапленную машину - может взять SCM полноценный или ансибл ?
источник

D

Denis 災 nobody in DevOps
George Gaál
Петухон реально не сильно сложнее, чем баш
Только надо добавить возможность прямого вызова программ, без subprocess.call и прочих извратов
источник

GG

George Gaál in DevOps
а?
источник

GG

George Gaál in DevOps
как бы каждой задаче свой инструмент
источник

M

MAdMAx in DevOps
MAdMAx
ну опять же от задачи зависит конечно.
если надо взять файлик и распарсить его - то лучше петон
а если надо настроить удаленную машину, установить там ПО, собрать че-нить и т.д., то петоний мимо.
powershell вполне ок справляется )
у esxi кстати отличное расширение именно на powershell
из линукса даже пользую
источник

D

Denis 災 nobody in DevOps
George Gaál
Не Шелла, чел, а вместо Шелл скриптов
Некоторые шелл скрипты на нем и пишут, и даже есть курсы под это дело.
источник

D

Denis 災 nobody in DevOps
Dmitry Nagovitsin
Заменять ничего не надо, баш отлично решает узкий набор задач
Да. Вообще, баш как заббикс - есть своя узкая сфера когда он оптимален. А если пытаться его везде пихать, не надо ныть что в море задач он сливает
источник

k

kSandr in DevOps
Сравнивать скриптовый язык  и вебсервис )))  146% логики )
источник

k

kSandr in DevOps
Да. Вообще, C++ как заббикс - есть своя узкая сфера когда он оптимален. А если пытаться его везде пихать, не надо ныть что в море задач он сливает
источник

SC

Smoked Cheese in DevOps
Denis 災 nobody
Только надо добавить возможность прямого вызова программ, без subprocess.call и прочих извратов
https://github.com/Luavis/sherlock.py#library никто ж не мешает сделать, это даже не очень сложно
источник

GG

George Gaál in DevOps
Shell script lanuage garuntee to run in most unix-like OS.
источник

GG

George Gaál in DevOps
После этого можно не читать
источник

LB

Let Eat Bee in DevOps
George Gaál
ЛОЛ. Мне не понравилось
а отлавливать баги вроде такого нравится?

set -ue;   #интернеты говорят, что так выйдет на всех ошибках
echo "A$(false)B"  # surprise mothefucker!
источник

GG

George Gaál in DevOps
Let Eat Bee
а отлавливать баги вроде такого нравится?

set -ue;   #интернеты говорят, что так выйдет на всех ошибках
echo "A$(false)B"  # surprise mothefucker!
Ну, ты ещё pipefail забыл и прочие прекрасные штуки.
источник

LB

Let Eat Bee in DevOps
ну давай, присыпь pipefail скрипт без пайпов :)
источник

GG

George Gaál in DevOps
В чем твой пойнт? В том, что баш боль для отладки? Ну, так это никто не отрицал
источник

GG

George Gaál in DevOps
А ты экранируешь все переменные ?
источник

GG

George Gaál in DevOps
Ну типа "${VAR_X}" вместо $VAR_X?
источник

LB

Let Eat Bee in DevOps
в том что powershell это решил и многое другое, при этом сохранил пайпы.  Вот тут нескольк фич сразу: как передать множество аргументов без мучений с экранированием и IFS (@{}), богатые типы ([TimeSpan]::Parse("00:05:00")) объекты на входе и выходе, а не тупые строки (.MetricValues) в powershell еще отличный job control, remoting over ssh на множество серверов,  всякие фильтры (греп и рядом не валялся), форматеры и прочее.

$MonitorParameters = @{
 ResourceId = "/subscriptions/$($(Get-AzContext).Subscription.Id)/resourceGroups/$resourceGroupName/providers/Microsoft.Sql/servers/$serverName/databases/$databaseName"
 TimeGrain = [TimeSpan]::Parse("00:05:00")
 MetricNames = "dtu_consumption_percent"
}
(Get-AzMetric @MonitorParameters -DetailedOutput).MetricValues
источник

D

Denis 災 nobody in DevOps
Схоронил
источник