S3 history
Чтобы что-то понять глубоко - нужно знать историю если не появления, но точно развития. Особенно это важно, если вы относите себя к девопсам - нужно обладать знаниями многих областей. Запомнить беконечные массивы информации об апишках, фреймворках и прочих настройках невозможно да и не нужно.
Нужно - понимать. А чтобы как раз понимать - нужно знать как оно было и почему стало как сейчас.
Итак, отметим лишь точку отсчёта:
https://aws.amazon.com/blogs/aws/amazon_s3/
В общем - #S3 вместе с #SQS и #EC2 ведут свой отсчёт с 2006-го года.
Это время расцвета VPS-хостингов со всей болью, помноженной на стоимость и ненадёжность при существенных нагрузках. Айфон лишь рождался, а крупным потребителям вычислительных мощностей всё приходилось делать самим. Потому с появлением первого крупного игрока, обещавшего SLA 99,99%, огромное количество будущих крупных клиентов Амазона бросились изучать возможности и стабильность его сервисов, в первую очередь S3.
Цена в 15 центов за гигабайт на то время была вполне себе конкурентной, потому основными в тестах была надёжность и стабильность доступа на протяжении длительного времени. Одними из первых крупных интересантов выступили штатовские универы, которые хотели избавиться от расходов на железо и перекинуть всё своё хозяйство в Амазон.
Через годик, убедившись в достаточной надёжности, они стали активно переходить туда.
За сим завершу литературно- и околомаркетинговое словоблудие о причинах и результатах создания S3. В следующей части перейду к суровым будням протодевопсов (их тогда ещё предательски называли сисадминами).
#s3_history #history
Чтобы что-то понять глубоко - нужно знать историю если не появления, но точно развития. Особенно это важно, если вы относите себя к девопсам - нужно обладать знаниями многих областей. Запомнить беконечные массивы информации об апишках, фреймворках и прочих настройках невозможно да и не нужно.
Нужно - понимать. А чтобы как раз понимать - нужно знать как оно было и почему стало как сейчас.
Итак, отметим лишь точку отсчёта:
https://aws.amazon.com/blogs/aws/amazon_s3/
В общем - #S3 вместе с #SQS и #EC2 ведут свой отсчёт с 2006-го года.
Это время расцвета VPS-хостингов со всей болью, помноженной на стоимость и ненадёжность при существенных нагрузках. Айфон лишь рождался, а крупным потребителям вычислительных мощностей всё приходилось делать самим. Потому с появлением первого крупного игрока, обещавшего SLA 99,99%, огромное количество будущих крупных клиентов Амазона бросились изучать возможности и стабильность его сервисов, в первую очередь S3.
Цена в 15 центов за гигабайт на то время была вполне себе конкурентной, потому основными в тестах была надёжность и стабильность доступа на протяжении длительного времени. Одними из первых крупных интересантов выступили штатовские универы, которые хотели избавиться от расходов на железо и перекинуть всё своё хозяйство в Амазон.
Через годик, убедившись в достаточной надёжности, они стали активно переходить туда.
За сим завершу литературно- и околомаркетинговое словоблудие о причинах и результатах создания S3. В следующей части перейду к суровым будням протодевопсов (их тогда ещё предательски называли сисадминами).
#s3_history #history
Amazon
Amazon S3 | Amazon Web Services
Earlier today we rolled out Amazon S3, our reliable, highly scalable, low-latency data storage service. Using SOAP and REST interfaces, developers can easily store any number of blocks of data in S3. Each block can be up to 5 GB in length, and is associated…
S3 нулевых
Впервые столкнулся с AWS лет десять назад - нужно было посмотреть-оценить, как он подходит к одному проекту для виндового бэкапа. В то время "облачный бэкап" был модной темой, про Амазон уже все знали, нужно было попробовать в действии.
Забегая вперёд, скажу, что тема с Амазоном не выгорела, т.к. даже спустя четыре года с момента открытия он держал планку в 15 центов за гигабайт, что в 2010-м году уже не выглядело конкурентным ни разу и потому выбор пал на покупку своих
Но не об этом. Хотя ещё чуть-чуть о нём. Через два года стартапный бэкап так не взлетел и на Амазон таки мы переехали. Денег было потрачено столько, что навсегда хватит, чтобы понимать, насколько удобен Амазон для стартапов.
Как же работали с S3 десять лет назад? Консоль - это же очевидно? Вот и я так думал.
Зарегистрировался на AWS, скачал Access Key ID и Secret Access Key. Зашёл в AWS Management Console, однако там всё лишь для управления виртуалками, вкладки с S3 нет. Как быть?
Оказалось, что для управления S3 через веб нужно было ставить сторонние утилиты, одним из самых популярных (бесплатных) был плагин под Firefox с незамысловатым названием S3Fox (полное название The FireFox S3 Organizer). Его же рекомендовали и пользовались сами амазоновцы.
Это было удивительно. Я знал Амазон как главного лидера в облакостроении, а чтобы пользоваться его сервисом, даже спустя четыре года после старта #S3 — нужно было ставить чужие плагинчики или шпилить в неудобную командную строку из-под жавы.
Только много-долго после я понял и осознал всю мощу такого подхода. Когда другие пилят пока не допилят, Амазон уже не один год эксплуатирует и продаёт, доделывая по ходу.
Так, я отвлёкся. S3Fox просто настраивался, имел FTP-подобный интерфейс, действительно просто позволял работать с бакетами. Однако эта схожесть с обычным файлохранилищем, но при этом отсутствие хоть какой-то возможности разграничить доступ - особо разочаровывала.
Владелец AWS аккаунта (root-юзер по-нынешнему) автоматически имел доступ во все бакеты, мог удалить все виртуалки и прочие ресурсы. Хочешь разделить на окружения или проекты - заводи новый аккаунт, новая кредитка, почта и так далее для каждого проекта. С точки зрения минимального compliance это сильно напрягало и усложняло даже просто финансовое обслуживание.
Кто ещё не понял - да, тогда ещё не было #Bucket_polices и #IAM. Их завезли позже в 2010-м и это очень важно запомнить. Почему важно - станет ясно потом.
Итого запишем главный результат лирического отступления - первобытные девопсы амазонили на S3 без всяческих политик. Юзали всевозможные плагины, рубились в руби командной строкой и дотошно логировали все проблемы доступности S3, покрывая жалобами девелоперский форум.
#s3_history #history
Впервые столкнулся с AWS лет десять назад - нужно было посмотреть-оценить, как он подходит к одному проекту для виндового бэкапа. В то время "облачный бэкап" был модной темой, про Амазон уже все знали, нужно было попробовать в действии.
Забегая вперёд, скажу, что тема с Амазоном не выгорела, т.к. даже спустя четыре года с момента открытия он держал планку в 15 центов за гигабайт, что в 2010-м году уже не выглядело конкурентным ни разу и потому выбор пал на покупку своих
dedicated servers. Руководству сложно и в наше время понять, зачем это вот всё дорогущее и ненужное, когда вот они, свои железяки и специально обученные админы в комплекте. А что уж говорить про десять лет тому.Но не об этом. Хотя ещё чуть-чуть о нём. Через два года стартапный бэкап так не взлетел и на Амазон таки мы переехали. Денег было потрачено столько, что навсегда хватит, чтобы понимать, насколько удобен Амазон для стартапов.
Как же работали с S3 десять лет назад? Консоль - это же очевидно? Вот и я так думал.
Зарегистрировался на AWS, скачал Access Key ID и Secret Access Key. Зашёл в AWS Management Console, однако там всё лишь для управления виртуалками, вкладки с S3 нет. Как быть?
Оказалось, что для управления S3 через веб нужно было ставить сторонние утилиты, одним из самых популярных (бесплатных) был плагин под Firefox с незамысловатым названием S3Fox (полное название The FireFox S3 Organizer). Его же рекомендовали и пользовались сами амазоновцы.
Это было удивительно. Я знал Амазон как главного лидера в облакостроении, а чтобы пользоваться его сервисом, даже спустя четыре года после старта #S3 — нужно было ставить чужие плагинчики или шпилить в неудобную командную строку из-под жавы.
Только много-долго после я понял и осознал всю мощу такого подхода. Когда другие пилят пока не допилят, Амазон уже не один год эксплуатирует и продаёт, доделывая по ходу.
Так, я отвлёкся. S3Fox просто настраивался, имел FTP-подобный интерфейс, действительно просто позволял работать с бакетами. Однако эта схожесть с обычным файлохранилищем, но при этом отсутствие хоть какой-то возможности разграничить доступ - особо разочаровывала.
Владелец AWS аккаунта (root-юзер по-нынешнему) автоматически имел доступ во все бакеты, мог удалить все виртуалки и прочие ресурсы. Хочешь разделить на окружения или проекты - заводи новый аккаунт, новая кредитка, почта и так далее для каждого проекта. С точки зрения минимального compliance это сильно напрягало и усложняло даже просто финансовое обслуживание.
Кто ещё не понял - да, тогда ещё не было #Bucket_polices и #IAM. Их завезли позже в 2010-м и это очень важно запомнить. Почему важно - станет ясно потом.
Итого запишем главный результат лирического отступления - первобытные девопсы амазонили на S3 без всяческих политик. Юзали всевозможные плагины, рубились в руби командной строкой и дотошно логировали все проблемы доступности S3, покрывая жалобами девелоперский форум.
#s3_history #history
S3 invention
Разбираясь с исторической точки зрения, нельзя не упомянуть про ещё один полезный подход, который очень эффективен для того, чтобы понять и разобраться, а не только запомнить. Это когда пытаешься сам изобрести, создать, придумать и настроить ту штуку, которая интересует. В данном случае - Amazon S3.
Итак, отбросим причины и прочую мишуру, оставим чисто техзадание, каким оно могло быть, зная, каким был результат.
1. Нужно иметь возможность закидывать файлы в будущее хранилище (а также, понятно, удалять и др. стандартные операции для файлов).
2. Нужна возможность делать эти файлы как приватными, так и доступными из интернета.
Вопросы доступности, устойчивости к нагрузками и прочие надёжности нас здесь не интересуют — нас интересует, как бы мы сделали, так сказать, "админку" или, по-правильному, какое API бы использовали для этого.
Имея представление о привычной файловой системе в линукс с её ACL расширением - логично использовать что-то типа, только с поправкой на будущее объектное хранилище.
Если кто не в курсе, что в линуксе кроме привычной схемы
---
Итак, у нас будут клиенты, они будут к нам логиниться в свои аккаунты и авторизоваться через апи - это будут типа юзеры из линукса.
У нас будут бакеты, которые создают юзеры и в которые они могут писать свои файлы - это будут типа папки из линукса.
Юзер всегда имеет полные права на свои бакеты и файлы в них. Он должен иметь возможность давать права писать в свои бакеты другим юзерам. Для этого у бакета добавим ACL, аналогичный ACL из линукса.
Аналогично для объектов, потому как и бакету, добавим каждому объекту свой ACL.
Объекты нужно иметь возможность делать публичными (доступными для других через интернет). Для этого добавим группу, принадлежа к которой, объект или бакет станет публичным - это будут типа группы из линукса.
===
Вроде всё. Просто, без замудренностей и должно работать - ведь работает в линуксе, верно?
Только что, в нескольких абзацах, мы заново изобрели #S3. Оно, действительно, работает. И, что важно, оно, дейстительно, работает так. Или точней и ещё более важней - так работало.
#s3_history #history
Разбираясь с исторической точки зрения, нельзя не упомянуть про ещё один полезный подход, который очень эффективен для того, чтобы понять и разобраться, а не только запомнить. Это когда пытаешься сам изобрести, создать, придумать и настроить ту штуку, которая интересует. В данном случае - Amazon S3.
Итак, отбросим причины и прочую мишуру, оставим чисто техзадание, каким оно могло быть, зная, каким был результат.
1. Нужно иметь возможность закидывать файлы в будущее хранилище (а также, понятно, удалять и др. стандартные операции для файлов).
2. Нужна возможность делать эти файлы как приватными, так и доступными из интернета.
Вопросы доступности, устойчивости к нагрузками и прочие надёжности нас здесь не интересуют — нас интересует, как бы мы сделали, так сказать, "админку" или, по-правильному, какое API бы использовали для этого.
Имея представление о привычной файловой системе в линукс с её ACL расширением - логично использовать что-то типа, только с поправкой на будущее объектное хранилище.
Если кто не в курсе, что в линуксе кроме привычной схемы
user:group можно использовать и ACL - погуглите по getfacl и setfacl.---
Итак, у нас будут клиенты, они будут к нам логиниться в свои аккаунты и авторизоваться через апи - это будут типа юзеры из линукса.
У нас будут бакеты, которые создают юзеры и в которые они могут писать свои файлы - это будут типа папки из линукса.
Юзер всегда имеет полные права на свои бакеты и файлы в них. Он должен иметь возможность давать права писать в свои бакеты другим юзерам. Для этого у бакета добавим ACL, аналогичный ACL из линукса.
Аналогично для объектов, потому как и бакету, добавим каждому объекту свой ACL.
Объекты нужно иметь возможность делать публичными (доступными для других через интернет). Для этого добавим группу, принадлежа к которой, объект или бакет станет публичным - это будут типа группы из линукса.
===
Вроде всё. Просто, без замудренностей и должно работать - ведь работает в линуксе, верно?
Только что, в нескольких абзацах, мы заново изобрели #S3. Оно, действительно, работает. И, что важно, оно, дейстительно, работает так. Или точней и ещё более важней - так работало.
#s3_history #history
S3 bucket ACL cross-account access
С одной стороны, многим, если не большинству, кто ходил больше раза в амазоновскую консоль, знакома закладка Access Control List в разделе Permissions.
С другой стороны, многим, если не большинству, даже из тех, кто потыкался и попытался разобраться, так и осталось тайной, что она в реальности собой представляет и как там что-то работает. Потому что погуглив получение Canonical ID и попыташись с помощью него расшарить доступ в бакет из другого аккаунта - наверняка ничего не работало.
Понятной документации не так много, т.к. во всей новой не рекомендуется использовать ACL, а пользоваться для этого (кросс-аккаунта, да и всего прочего) Bucket Policy и IAM.
Но оно ж там ещё почему-то есть! Если бы не работало, убрали бы, наверное.
Ларчик открывается просто. Если у вас не заработало, значит вы честно выполняли рекомендации бестпрактиксов и делали это не из-под root-юзера, т.е. логинились в консоль как обычный IAM-юзер. А для того, чтобы эти артефакты работали и работали как надо - требуются руты и только руты.
Т.е. работать и логиниться в консоль для работы с ACL нужно из-под рута, шарить доступ в другой аккаунт и там тоже только рут (для консоли) и credentials рута (если программно). И никаких ролей.
Почему? Это было в предыдущих частях по #s3_history - мы же ведь ещё не придумали #bucket_policy и #IAM, у нас на дворе нулевые, а их завезли лишь в 2010-м. Поэтому только руты, только #ACL, только хардкор.
С одной стороны, многим, если не большинству, кто ходил больше раза в амазоновскую консоль, знакома закладка Access Control List в разделе Permissions.
С другой стороны, многим, если не большинству, даже из тех, кто потыкался и попытался разобраться, так и осталось тайной, что она в реальности собой представляет и как там что-то работает. Потому что погуглив получение Canonical ID и попыташись с помощью него расшарить доступ в бакет из другого аккаунта - наверняка ничего не работало.
Понятной документации не так много, т.к. во всей новой не рекомендуется использовать ACL, а пользоваться для этого (кросс-аккаунта, да и всего прочего) Bucket Policy и IAM.
Но оно ж там ещё почему-то есть! Если бы не работало, убрали бы, наверное.
Ларчик открывается просто. Если у вас не заработало, значит вы честно выполняли рекомендации бестпрактиксов и делали это не из-под root-юзера, т.е. логинились в консоль как обычный IAM-юзер. А для того, чтобы эти артефакты работали и работали как надо - требуются руты и только руты.
Т.е. работать и логиниться в консоль для работы с ACL нужно из-под рута, шарить доступ в другой аккаунт и там тоже только рут (для консоли) и credentials рута (если программно). И никаких ролей.
Почему? Это было в предыдущих частях по #s3_history - мы же ведь ещё не придумали #bucket_policy и #IAM, у нас на дворе нулевые, а их завезли лишь в 2010-м. Поэтому только руты, только #ACL, только хардкор.