Tag: 2017

Opublikowane w

Allegro Tech Talks Poznań #4 – wrażenia

W projekcie abcc panuje chwilowy zastój, spowodowany czynnikami różnymi – od osobistych (bardziej, znacznie bardziej), przez zawodowe (mniej, znacznie mniej), ale faktem jest, że spocząłem na laurach nieco i nic się od ostatniego wpisu nie zmieniło w temacie. Plan jest taki, żeby uruchomić sobie stację testową opartą o Raspbbery Pi, która będzie działać na dwóch lub trzech łączach (kabel, modem GSM i być może, jeśli RPi wyrobi prądowo, karta WiFi) i zrzucać pomiary, w celu lepszego dobrania parametrów. Ale to plany…

Tymczasem w ramach pożeraczy czasu byłem w zeszłym tygodniu na spotkaniu Allegro Tech Talks Poznań #4. Staram się bywać, jeśli akurat mam czas. Jeśli dobrze zrozumiałem, po raz pierwszy można było wysłuchać przez net na żywo, ale jakoś nie przepadam za taką formą – lepiej mi się obiera na żywo, nie mam nawyku słuchania przez net. No i zawsze można spotkać znajomych i poplotkować.

Prezentacje były dwie, obie dotyczyły Apache Solr, więc zupełnie nie moja działka, i przyznaję, że wahłem się, czy w ogóle iść, ale obie były IMO bardzo dobrze i interesująco poprowadzone, więc części merytorycznej też nie żałuję.

Pierwsza prezentacja dotyczyła uruchamiania Solra w kontenerach dockerowych, poczynając od tego jak to skonfigurować i uruchomić, przez przedstawienie wyników benchmarków pomiędzy sprzętem fizycznym (bare metal), przez pełną wirtualizację, po kontenery. Różnice były duże, przedstawione dane przekonują do kontenerów, ale… Zawsze jest jakieś ale, w tym przypadku testy były robione na ustawieniach domyślnych. Z jednej strony rozumiem, bo jakiś wspólny mianownik trzeba mieć, z drugiej produkcję konfiguruje się pod konkretny przypadek. Niemniej, różnice były na tyle istotne, że konfiguracja raczej nie będzie w stanie ich zniwelować. W sumie można było traktować tę prezentację mniej jako o Solr, bardziej jako o dockerze.

Druga prezentacja dotyczyła optymalizacji Solra w Allegro. Jak pisałem, nie moja działka, więc momentami była to trochę chińszczyzna (na zasadzie: nie wiem co to dokładnie jest), ale opowiedziane przystępnie, ciekawie i z przykładami. Mocno nieoczywiste przypadki i wyniki, efekty dobre. Stawiam, że dla osób zajmujących się Solrem perełka. Jest dostępna w wersji online.

Spotkałem też starych znajomych i poplotkowaliśmy, więc ogólnie bardzo udane wydarzenie – 10/10.

Opublikowane w

5 powodów do udziału w DSP2017

Nie jestem programistą i nie jest to blog programistyczny[1]. Czemu więc dołączyłem do konkursu Daj Się Poznać 2017?

  • Po pierwsze, uważam, że to świetna inicjatywa, dobra zabawa i doskonały motywator.
  • Po drugie, zawsze lubiłem konkursy programistyczne typu Potyczki Alogrytmiczne.
  • Po trzecie, uważam, że administrator powinien znać przynajmniej podstawy programowania, nawet jeśli nie udziela się programistycznie w większych projektach. Zresztą, devops (modne słowo) way to konfiguracja jako kod i bez przynajmniej podstaw jest… ciężko. Jeśli w ogóle się da. 😉
  • Po czwarte, ostatnio spodobał mi się Python i jest okazja, żeby poćwiczyć.
  • Po piąte, mam pomysł na mały projekt, który trafił do szuflady (czytaj: na dysk) i DSP2017 jest świetną okazją, żeby go zmaterializować. Jak to ładnie ktoś ujął „wizja bez implementacji to halucynacja”.

Największy problem sprawiła mi… platforma bloga czyli sam Blox. Wymogiem uczestnictwa w DSP2017 jest podanie kanału RSS, na którym będą pojawiały się wpisy konkursowe. I tylko one. Niestety, nic takiego tu nie istnieje, przynajmniej nie w nowym szablonie. Zgłosiłem to na forum, mają sprawdzać, ale złudzeń nie mam – muszę radzić sobie sam. Jest plan, szczegóły jutro.

Konkursem zainteresowałem się bliżej 28. lutego i powyższy problem sprawił, że pierwotnie odpuściłem, na szczęście zapisy do DSP2017 zostały przedłużone do 12. marca, więc podobnie jak ja macie jeszcze szansę zdążyć się zarejestrować.

Do całości podchodzę luźno – ma to być głównie motywator do materializacji projektu i okazja do poćwiczenia Pythona. Biorąc pod uwagę ilość wpisów na blogu, głównym problemem mogą być same dwa wpisy tygodniowo, a szczególnie ten drugi, niekoniecznie związany z projektem. A jeszcze trzeba sam projekt realizować… Niemniej, trzeba próbować. 🙂

[1] Mam nadzieję, że to wyznanie nie spowoduje dyskwalifikacji. Postaram się spełnić wymagania konkursowe.

Opublikowane w

Nginx z automatycznym odnawianiem certyfikatu SSL, HTTP/2 i A+

Artykuł na z3s o automatycznym odnawianiu darmowego certyfikatu SSL od Let’s Encrypt przypomniał mi, że nie skończyłem sprawy z nginx i certyfikatami SSL i oceną A+. Po pierwsze, brakowało mi wpisu w cronie. Trzy miesiące to jednak kawał czasu, a na serwer i tak się logowałem, więc certyfikaty były odświeżane ręcznie. No ale jak robić to porządnie, czyli w pełni automatycznie.

Wpis do crontab, którego używam to:

43 3 * * 2 /usr/bin/certbot renew --post-hook "service nginx reload" >> /var/log/certbot.log

Nie jest idealny – przede wszystkim restart nginx będzie wykonywany przy każdej próbie przeładowania, czyli raz na tydzień. Wydaje mi się, że przedładowanie konfiguracji nie będzie stanowiło problemu. Ale jeśli komuś przeszkadza, to polecam zainteresowanie się opcją –renew-hook, zamiast –post-hook. Wykonuje się ona tylko przy odświeżeniu certyfikatu (czyli raz na kwartał). Z tym, że mam kilka certyfikatów i nie jestem przekonany, że restart nginx podczas odświeżania certyfikatu to jest to, co chcę robić. A testować mi się nie chce, tym bardziej, że na sucho średnio jest jak.

Rozwiązałem sprawę nie do końca działającego HTTP/2 (problemy z Firefox) opisaną w poprzednim wpisie. Przyczyna wskazana w komentarzach była trafna, żeby było ciekawiej, korzystałem dokładnie z

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL';

tyle, że zapewne podczas zabaw ze zwiększaniem kompatybilności z przeglądarkami zmieniłem to na wersję z gotowca, a potem odkręciłem ale… nie wszędzie. Poza tym, dopisanie http2 w każdej linii listen zawierajacej ssl i jest HTTP/2. Trochę sztuka dla sztuki. Jak pokazały testy szybkości, ale wynika to głównie z tego, że same strony są małe i lekkie. Albo, jak Planeta Joggera, korzystają głównie z zasobów zewnętrznych, więc zmiany na moim serwerze nic nie dają.

W każdym razie powyższe szyfry i włącznie HSTS wystarczają do uzyskania dla nginx oceny A+ na teście SSL. Czego w nadchodzącym 2017 wszystkim życzę, korzystając z tego, że wpis przeleżał w szkicach nieco dłużej, niż planowałem.